Как я могу заблокировать свою собственную учетную запись от удаленного входа в систему ssh с паролем?

for цикл прекрасен здесь. Но обратите внимание, что это вызвано тем, что файл содержит названия машины, которые не содержат пробельных символов или globbing символов. for x in $(cat file); do … не работает для итерации по строкам file в целом, потому что оболочка сначала разделяет вывод от команды cat file где угодно существует пробел и затем рассматривает каждое слово как шаблон шарика так \[?* далее расширены. Можно сделать for x in $(cat file) безопасный, если Вы работаете над ним:

set -f
IFS='
'
for x in $(cat file); do …

Связанное чтение: Цикличное выполнение через файлы с пробелами на имена?; Как я могу читать линию за линией из переменной в ударе?; Почему while IFS= read используемый так часто, вместо IFS=; while read..? Отметьте это при использовании while read, безопасный синтаксис для чтения строк while IFS= read -r line; do ….

Теперь давайте обратимся к тому, что идет не так, как надо с Вашим while read попытка. Перенаправление из файла списка сервера относится к целому циклу. Итак, когда ssh выполнения, его стандартный вход прибывает из того файла. ssh клиент не может знать, когда удаленное приложение могло бы хотеть читать из своего стандартного входа. Таким образом, как только ssh клиент замечает некоторый вход, он отправляет тот вход удаленной стороне. ssh сервер там затем готов подать тот вход к удаленной команде, должен это хотеть это. В Вашем случае удаленная команда никогда не читает входа, таким образом, данные заканчиваются отброшенные, но сторона клиента ничего не знает об этом. Ваша попытка с echo работавший, потому что echo никогда читают любой вход, он оставляет свой стандартный вход в покое.

Существует несколько способов, которыми можно избежать этого. Можно сказать ssh не читать из стандартного входа, с -n опция.

while read server; do
  ssh -n $server "uname -a"
done < /home/kenny/list_of_servers.txt

-n опция на самом деле говорит ssh перенаправить его вход от /dev/null. Можно сделать это на уровне оболочки, и он будет работать на любую команду.

while read server; do
  ssh $server "uname -a" 

Заманчивый метод для предотвращения входа ssh, прибывающего из файла, должен поставить перенаправление read команда: while read server . Это не будет работать, потому что это заставляет файл быть открытым снова каждый раз read команда выполняется (таким образом, она считала бы первую строку файла много раз). Перенаправление должно быть на целом цикле с условием продолжения так, чтобы файл был открыт однажды на время цикла.

Общее решение состоит в том, чтобы предоставить вход циклу на дескрипторе файла кроме стандартного входа. Оболочка имеет конструкции для переправления ввода и вывода от одного числа дескриптора до другого. Здесь, мы открываем файл на дескрипторе файла 3 и перенаправляем read стандартный вход команды от дескриптора файла 3. ssh клиент игнорирует открытые нестандартные дескрипторы, таким образом, все хорошо.

while read server <&3; do
  ssh $server "uname -a"
done 3

В ударе, read команда имеет определенную опцию читать из другого дескриптора файла, таким образом, можно записать read -u3 server.

Связанное чтение: Дескрипторы файлов и сценарии оболочки; Когда Вы использовали бы дополнительный дескриптор файла?

10
27.05.2011, 07:44
3 ответа

Можно использовать опцию Match в sshd_config

Соответствие Представляет условный блок. Если все критерии на строке Соответствия удовлетворены, ключевые слова на следующих строках переопределяют установленных в глобальном разделе файла конфигурации, или до другой строки Соответствия или до конца файла. [1]

Так, в конце того файла Вы могли указать:

Match User yourusername
PasswordAuthentication no

Посмотрите man 5 sshd_config для всех доступных вариантов.

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5

9
27.01.2020, 20:02
  • 1
    Это уже хорошо, но я хочу видеть, могу ли я обойтись без редактирования sshd_config. –  phunehehe 27.05.2011, 08:45
  • 2
    Учитывая Вас желают внести системное изменение, т.е., тот, который не влияет на других пользователей, который, кажется, маловероятен... –  jasonwryan 27.05.2011, 09:35
  • 3
    и что относительно ~/.ssh/config? Вы попробовали включая настройки там? –  ttyS0 27.05.2011, 18:15
  • 4
    AFAK ~/.ssh/config в для клиента, не сервера. –  Adam Byrtek 27.05.2011, 21:12

Ответ от jasonwryan будет правильным способом внести это изменение. Единственное дополнение, которое я сделал бы, состоит в том, что Вы могли установить соответствие, чтобы быть группой, базирующейся так, чтобы любые пользователи в группе колеса были обязаны использовать ключевую аутентификацию, в то время как другие могли использовать пароли.

Я знаю, что Вы хотите сделать это, не изменяя системные файлы конфигурации, но существует серьезное основание, почему это не будет возможно. В Вашей голове это имеет смысл, что Ваш пользователь должен смочь установить более безопасную политику входа в систему, но просто потому что в Вашем уме это - более безопасная опция, не изменяет то, что это - все еще изменение в системных требованиях входа в систему для удаленного пользователя.

Для понимания, почему это - проблема вообразите сценарий наоборот. Системный администратор (кто может изменить системные файлы конфигурации) устанавливает систему на основанный на ключе вход в систему только. Затем некоторый пользователь приезжает и только с доступом к их собственному пользовательскому файлу и устанавливает их учетную запись для разрешения аутентификации по паролю, переопределяя системную политику. BEEEEEEP. Проблема безопасности!

Это объясняет, почему вид изменения, которое Вы хотите внести, только возможен из системного файла конфигурации?

1
27.01.2020, 20:02
  • 1
    Трудно думать, что путь вокруг, с тех пор, если я был обычным пользователем, который не делает sudo, я могу счастливо настроить свои ключи, затем блокируют пароль, таким образом делая мою учетную запись "ключом только аутентификация". –  phunehehe 27.05.2011, 12:02
  • 2
    В другой мысли я мог заблокировать свой пароль каждый раз, когда я собираюсь выйти из системы, который должен запретить весь пароль, входят в систему для моей учетной записи. Затем, после того как я зарегистрирован с моими ключами, я мог включить пароль снова к sudo. Очевидно, это не хорошее решение, но это заставляет меня думать, что это возможно. –  phunehehe 27.05.2011, 12:03
  • 3
    Можно только сделать это, потому что системный администратор позволил ключевую аутентификацию, и Вы только добавляете ограничения для себя, ничего не изменяя. Отключение Вашего пароля просто устанавливает его на недопустимое значение, это не изменяет, какую аутентификацию системный демон позволяет. –  Caleb 27.05.2011, 12:06
  • 4
    "добавляющие ограничения для себя, ничего не изменяя", точно, что я желаю сделать. –  phunehehe 27.05.2011, 13:24
  • 5
    @Caleb: в разрешении не было бы никакой проблемы безопасности authorized_keys для помещения большего количества ограничений как, phunehehe хочет. Например, authorized_keys может ограничить определенные ключи к определенным командам. –  Gilles 'SO- stop being evil' 27.05.2011, 13:29

Добавляя ограничения для себя, ничего не изменяя

Почему не в стороне клиента, если бы это уверено, что ssh был бы клиентом, чтобы использоваться для попыток входа в систему? Если да, попытайтесь внести изменения в ssh_config вместо sshd_config. Проверьте на параметр 'PasswordAuthentication No' и PreferredAuthentications

0
27.01.2020, 20:02

Теги

Похожие вопросы