Я настраиваю сервер FreeIPA на CentOS 7 и хочу заблокировать аутентификацию RSA через SSH, когда срок действия пароля истек. По умолчанию, когда у меня истекает срок действия пароля пользователя, и они входят в систему, они вынуждены менять свой пароль. Но если тот же пользователь также использует аутентификацию RSA, сервер пропускает их и не заставляет их менять свой пароль. Я искал темы, связанные с FreeIPA, PAM и SSH, и не могу найти ответ, который ищу.
Есть ли способ заблокировать аутентификацию ключа RSA по SSH, когда срок действия пароля пользователя истек?
Если вы зарегистрировали клиента в FreeIPA, его стек PAM будет настроен на использование демона SSSD. Рассматриваемый модуль PAM - pam_sss, который обращается к демону SSSD для выполнения проверки. SSSD знает об атрибутах IPA и должен правильно запретить сеанс, когда пользователь заблокирован.
# ipa user-disable abbra
-----------------------------
Disabled user account "abbra"
-----------------------------
# grep UsePAM /etc/ssh/sshd_config
UsePAM yes
# journalctl -u sshd -f
.....
Feb 29 17:21:23 a.example.com systemd[1]: Started OpenSSH server daemon.
Feb 29 17:21:33 a.example.com sshd[20209]: pam_sss(sshd:account): system info: [The user account is locked on the server]
Feb 29 17:21:33 a.example.com sshd[20209]: pam_sss(sshd:account): Access denied for user abbra: 6 (Permission denied)
Feb 29 17:21:33 a.example.com sshd[20209]: fatal: Access denied for user abbra by PAM account configuration [preauth]
Для включенного пользователя у вас будет что-то вроде:
# ipa user-enable abbra
----------------------------
Enabled user account "abbra"
----------------------------
# journalctl -u sshd -f
....
Feb 29 18:03:27 a.example.com sshd[22302]: Accepted publickey for abbra from X.Y.Z.W port 54540 ssh2: KEY...
Когда пароль помечен как просроченный (либо путем установки его другим пользователем, то есть администратором, либо путем применения определенной политики паролей), SSSD игнорирует тот факт, что пароль требует изменения, потому что на этом этапе он запускает только фазу учетной записи, где пароли не т проверил.
Раньше было несколько запросов на добавление такой логики, и одним из аргументов против этого был тот факт, что если вы используете один тип аутентификации (открытый ключ), почему статус учетной записи должен основываться на состоянии другой аутентификации тип. В этом есть логика, но, возможно, было бы неплохо добавить политику паролей, которая позволяет логике связывать состояние учетной записи с состоянием пароля.
Если вы заинтересованы в такой политике паролей, я бы порекомендовал открыть тикет FreeIPA, чтобы запросить ее, с объяснением вашего варианта использования.
Если вы используете PAM для создания сеанса для своих пользователей (usePAM yes), это не позволит пользователю войти в систему с просроченными паролями.
Это красиво описано на Unix (хорошо, это обратная проблема, но может быть вам полезна).
Вероятно, вы могли бы создать сценарий, используя chage или usermod, например: usermod --expiredate ... Если бы мне пришлось, я бы использовал сценарий оболочки, похожий на следующий псевдокод:
if `chage -l user_account_you_want_expired_etc | awk '/expires/{print "relevant fields}'` >= expiration
then
usermod -s /sbin/nologin USERNAME
fi
Что-то в этом роде (имейте в виду, что это не работает, но что-то, что дает вам структуру. "Если срок действия (grep'd из awk) больше или равен тому, что я хочу / нужно, то измените оболочку на нологин ".