Intereting Posts
Новый индексный дескриптор при установке новой файловой системы Проблема IPSec VPN с туннелем. SSH и ddns: могут подключаться удаленно, но не локально chcon: не может применять частичный контекст к немеченому файлу при установке nagios с SELinux Как настроить Linux для того, чтобы не требовать sudo для определенных команд для определенных пользователей? Книги / Руководства по обеспечению безопасности сервера Чтение списков пакетов … Ошибка! Как создать учетную запись пользователя с определенными разрешениями? Воспроизведение флэш-анимации в замедленном режиме в Linux Есть ли способ настроить яркость монитора? Существуют ли программы или команды CLI для управления файлами * .gdbm Как я могу скомпилировать unclutter для моего встроенного Linux? (новичок) awk не печатает $ 2 из файла? могу ли я настроить SSH, чтобы он не использовал шифрование? Список всех подключенных устройств в FreeBSD

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

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

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

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

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

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

А ТАКЖЕ

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

А ТАКЖЕ

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

А ТАКЖЕ

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

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

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

Этот вопрос изначально упоминал passwd --delete что небезопасно : при этом поле зашифрованного пароля в /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 . До 2008 года passwd -l , происходящий из набора shadow источника, использовался для этого в дополнение к префиксу пароля с восклицательным знаком – но больше не делает этого.

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

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

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