Я выполнил инструкции 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 для проверки отправленного ключа, поэтому он должен работать таким образом) Единственное исключение - когда вы запускаете индивидуальную конфигурацию, которая также требует успеха внутри интерактивной клавиатуры. Так как это не по умолчанию, ваш стек аутентификации почти наверняка игнорируется во время этих аутентификаций.
Хотя стек учетной записи
- это обычно , где вы устанавливаете ограничения на вход только с открытым ключом, Я не верю, что здесь это сработает, так как вам сначала нужно будет успешно пройти аутентификацию для вызова модуля PAM. Если ваш модуль PAM не вызывается, он не может увеличивать счетчик при каждом неудачном входе в систему.
Единственный способ увидеть, как это работает, - это настроить конфигурацию sshd таким образом, чтобы она требовала интерактивной аутентификации с клавиатуры в дополнение к аутентификации с открытым ключом . (вы можете использовать эти вопросы и ответы в качестве отправной точки). Тем не менее, как указывает JohnA, остается спорным вопрос, действительно ли это принесет какую-либо ценность.
Я почти уверен, что вы не сможете использовать PAM в этом качестве. Если у пользователя нет закрытого ключа ssh, соответствующего общедоступному ключу ssh на сервере, то он не сможет пройти аутентификацию.
Целью блокировки при сбое пароля является предотвращение подбора пароля для пользователя. Счет. Если применяется аутентификация с использованием ssh-ключа, пароль учетной записи пользователя не учитывается.
В случае пароля, который запрашивается для аутентификации ssh-ключа, это пароль для закрытого ключа. Отсутствие аутентификации по закрытому ключу не приводит к отказу аутентификации на сервере.