Я следовал инструкциям Redhat о том, как усилить аутентификацию на сервере Linux, но мы используем только SSH с аутентификацией с открытым ключом. Согласно этим инструкциям: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-harpting_your_system_with_tools_and_services
Вот мои файлы /etc/pam.d/system-auth и /etc/pam.d/password-auth, на самом деле они одинаковы:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_faillock.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
С этой конфигурацией я надеялся получить какое-то сообщение о блокировке, если пользователь, например, пытается аутентифицироваться с неправильным ключом после 3 попыток. Но сообщение о блокировке не появляется, и я не могу сказать, работает политика блокировки или нет. Существует также модуль pam_tally2, но я не вижу, чем он отличается от модуля pam_faillock.
Журналы ничего не показывают, кроме отказа в праве root:
[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/some_user
[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/root
cat: /var/run/faillock/root: Permission denied
И я пытался использовать неправильный ключ для ssh для some_user, и, похоже, это не блокирует меня, потому что я ничего не вижу в журналах блокировки при сбое или каких-либо сообщениях ssh, откуда я пытаюсь выполнить ssh.
Проблема в том, что вы пытаетесь применить эти политики внутри стека аутентификации.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_faillock.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
Аутентификация с открытым ключом, реализованная в самом демоне SSH, обходит стек аутентификации. (здесь не вызывается модуль аутентификации PAM для проверки отправленного ключа, поэтому он должен работать таким образом) Единственное исключение - когда вы запускаете индивидуальную конфигурацию, которая также требует успеха внутри интерактивной клавиатуры. Поскольку это не по умолчанию, ваш стек аутентификации почти наверняка игнорируется во время этих аутентификаций.
В то время account стек обычно там, где вы устанавливаете ограничения на вход только с открытым ключом, я не верю, что здесь это сработает, поскольку вам сначала нужно будет успешно пройти аутентификацию для вызова модуля PAM. Если ваш модуль PAM не вызывается, он не может увеличивать счетчик при каждом неудачном входе в систему.
Единственный способ увидеть, как это работает, - это настроить конфигурацию sshd таким образом, чтобы она требовала интерактивной аутентификации с клавиатуры. в дополнении к аутентификация с открытым ключом. (ты можешь использовать этот вопрос и ответ в качестве отправной точки) Тем не менее, как указывает JohnA, вопрос о том, действительно ли это будет иметь какую-либо ценность, является спорным.
Я почти уверен, что вы не сможете использовать PAM в этом качестве. Если у пользователя нет закрытого ключа ssh, соответствующего открытому ключу ssh на сервере, он не сможет пройти аутентификацию.
Блокировка сбоя пароля предназначена для предотвращения подбора пароля для учетной записи пользователя. Если применяется аутентификация по ключу ssh, пароль учетной записи пользователя не учитывается.
В случае пароля, который запрашивается для аутентификации ssh-ключа, это пароль для закрытого ключа. Отсутствие аутентификации с использованием закрытого ключа не приводит к отказу аутентификации на сервере.