Должен ли я удалять пароли пользователей после настройки аутентификации с открытым ключом для SSH?

Лучше использовать открытые ключи для SSH. Так что мой sshd_configимеет PasswordAuthentication no.

Некоторые пользователи никогда не входят в систему, например, пользователь sftp с оболочкой /usr/sbin/nologin. Или системный аккаунт.

Таким образом, я могу создать такого пользователя без пароля с adduser gary --shell /usr/sbin/nologin --disabled-password.

Это хорошая / плохая идея? Есть ли последствия, которые я не рассматривал?

— Lonix
источник

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

— Доктор J

Ответы:

Если у вас есть root-доступ к серверу и вы можете сгенерировать ssh-ключи для своих пользователей в случае их потери

Вы уверены, что у пользователя (как человека) не будет нескольких учетных записей, и им нужно переключаться между ними в сеансе SSH (ну, они также могут открыть несколько сеансов SSH, если возникнет такая необходимость)

им никогда не понадобится «физический» (через клавиатуру + монитор или через удаленную консоль для ВМ) доступ к серверу

ни один пользователь не имеет доступа с паролем sudo(то есть у них либо нет доступа к sudo, либо он имеет доступ к sudo NOPASSWD)

Я думаю, что ты будешь хорошим.

У нас на работе настроено много серверов (только некоторым учетным записям необходим доступ к виртуальной машине через удаленную консоль vmware, другие подключаются только через SSH с аутентификацией pubkey).

— Мистер Шунц
источник

Я также добавил бы: «Вы знаете, что пользователям никогда не придется обращаться к системе из удаленных систем, у которых нет своего закрытого ключа SSH». И «Вы готовы иметь дело с пользователями, которые сталкиваются с ситуацией, о которой вы не задумывались».

— Эндрю Хенле

Первое условие ИМО не обязательно. Ваши пользователи должны сами создавать свои ключи. Вы просто авторизуете их открытые ключи, поскольку они дают их вам. Если они потеряют ключ, они просто сгенерируют другой, и вы замените старый на сервере.

— Кристоф Древет-Дроге

@AndrewHenle Это хороший момент, однако, если sshd имеет, PasswordAuthentication noто это другая проблема (пользователь не сможет войти в любом случае).

— Ионикс

«Никогда» не бывает так долго. Администратор может легко добавить аутентификацию по паролю в случае необходимости.

— Hyde

Что ж, вопрос явно относится к учетным записям, которые определенно не (и, вероятно, не должны) входить в систему, например, к системным учетным записям, используемым определенными службами или только для пользователей sftp. В вопросе также говорится, что у пользователей нет логина. Для этих типов пользователей, я думаю, желательно явно отключить вход через пароль.

— Кристиан Гаврон

Этот вопрос изначально упоминался, passwd --delete <username> что небезопасно : при этом поле зашифрованного пароля в /etc/shadowбудет полностью пустым.

username::...

Если вы настроили ваш sshdотказ от аутентификации по паролю, то это безопасно с SSH ... Но если любая другая служба в вашей системе использует аутентификацию по паролю и не настроена на отклонение пустых паролей, это позволяет получить доступ без пароля! Ты не хочешь этого.

adduser --disabled-passwdсоздаст /etc/shadowзапись, где поле зашифрованного пароля будет просто звездочкой, т.е.

username:*:...

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

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

Если вам нужно установить существующую учетную запись в это состояние, вы можете использовать эту команду:

echo 'username:*' | chpasswd -e

Существует третье специальное значение для поля зашифрованного пароля: adduser --disabled-loginтогда поле будет содержать только один восклицательный знак.

username:!:...

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

Но вот ловушка для неосторожных: в 2008 году версия passwdкоманды, которая приходит из старого shadowпакета, была изменена с того, чтобы переопределить ее passwd -lс «блокировки учетной записи» на «блокировку пароля». Заявленная причина - «для совместимости с другой версией passwd».

Если вы (как и я) узнали это давно, это может стать неприятным сюрпризом. Это не помогает вопросам, которые adduser(8), очевидно, еще не знают об этом различии.

Та часть , которая блокирует учетную запись для всех методов аутентификации фактически устанавливая значение даты истечения срока действия 1 за счет: usermod --expiredate 1 <username>. До 2008 года passwd -lэто происходит из shadowисходного комплекта, используемого для этого, в дополнение к префиксу пароля с восклицательным знаком - но больше не делает этого.

Список изменений пакета Debian гласит:

debian / patches / 494_passwd_lock-no_account_lock: восстановить предыдущее поведение passwd -l (которое изменилось в # 389183): блокировать только пароль пользователя, но не его учетную запись. Также четко документируйте различия. Это восстанавливает поведение, общее с предыдущими версиями passwd и другими реализациями. Закрывается: # 492307

Истории ошибок для ошибок Debian 492307 и 389183 могут быть полезны для понимания того, что стоит за этим.

— Телком
источник

Спасибо за предупреждение ... Я собираюсь отредактировать вопрос, чтобы никто не делал эту ошибку!

— Ионикс

Относится ли ваше предупреждение также к случаю, когда я использую adduser --disabled-passwd- поэтому, если какой-либо другой сервис разрешает аутентификацию по паролю, тогда пользователь может войти без пароля?

— Ионикс

Нет, в adduser --disabled-passwordчастности, проверка подлинности пароля невозможна для этой учетной записи.

— TelcoM

Поскольку удаление пароля кажется таким невинным, но настолько опасным, я предлагаю поменять абзац на него абзацем об использовании, *чтобы люди читали его первым.

— Капитан Мэн

Вау, это неприятный сюрприз, ожидающий случиться ... и, как обычно, очевидно, что в этом виновата проблема совместимости. Он появился в passwdисходном коде в 2008 году. Разве вам не нравится, когда что-то, чему вы когда-то научились, а затем положились, уже не так?

— Телеком