☰

PAM を使用して SSH 公開鍵認証方式のロックアウト ポリシーを管理する方法

tag-icon • tag-icon ssh authentication pam public-key password-policy
PAM を使用して SSH 公開鍵認証方式のロックアウト ポリシーを管理する方法

Linux サーバーで認証を強化する方法については RedHat の指示に従いましたが、公開キー認証の SSH のみを使用しています。これらの指示によると: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_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 モジュールと比べてどのような違いがあるのか​​わかりません。

ログには、ルート権限が拒否されたこと以外は何も表示されません。

[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 メッセージには何も表示されないため、ロックアウトされていないようです。

答え1

問題は、これらのポリシーを認証スタック内で適用しようとしていることです。

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 認証モジュールがないので、そのように動作する必要があります) 唯一の例外は、keyboard-interactive 内でも成功を必要とするカスタマイズされた構成を実行している場合です。これはデフォルトでないため、これらの認証中に認証スタックが無視されることはほぼ確実です。

スタックaccountがいつもの公開鍵のみのログインに制限を設ける場合、PAM モジュールを呼び出すにはまず認証に成功する必要があるため、ここでは機能しないと思います。PAM モジュールが呼び出されない場合、ログインが失敗するたびにカウントを増やすことはできません。

これが機能する唯一の方法は、sshd設定を調整してキーボードインタラクティブ認証を要求することです。に加えて公開鍵認証（このQ&A(出発点として) とはいえ、JohnA が指摘するように、これが本当に何らかの価値をもたらすかどうかは議論の余地があります。

答え2

この用途では PAM を使用できないことはほぼ確実です。ユーザーがサーバーの SSH 公開キーに対応する SSH 秘密キーを持っていない場合、認証できません。

パスワード失敗ロックアウトの目的は、ユーザー アカウントのパスワードの総当たり攻撃を防ぐことです。SSH キー認証が強制されている場合、考慮するユーザー アカウント パスワードはありません。

SSH キー認証に要求されるパスワードの場合、これは秘密キーのパスワードです。秘密キーに対する認証に失敗しても、サーバーへの認証は失敗しません。

関連情報