〜のように初めてログインしたときにのみメッセージを表示するようにpam_mountを設定します。ただし、推奨回答はRHEL 9では機能しません(元の質問では機能しないようです)。
Red Hat Enterprise Linux 9 で DUO 2 段階認証プロセスを設定する必要があります。指示するベンダーのウェブサイトの設定により、ユーザーがパスワードを入力するたびに2FAの質問に答えますsudo
。たとえば、最初のログイン時にのみ2FAの質問が表示されるようにこの設定を変更したいと思います。
以下を含む行の後に、/etc/authselect/password-authに以下を追加しましたpam_unix.so
。
auth [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
auth sufficient pam_duo.so
pam_succeed_if条件は、リンクされた質問とArch Wiki(独自の質問にリンクされている)の両方で提案されます。ただし、pam_succeed_if条件は毎回失敗し、DUOはシステムがロック解除されるたびに2FAを求めるメッセージを表示します。ユーザーがすでにログインしている場合は、DUOを確実にスキップする方法は?
答え1
最初のログインでのみ2FA認証を希望する場合は、pam_duo.so
最初のログインを処理するサービスのみを参照してください。
注意して次のサービスを明示的に一覧表示できます。はい2FAをスキップできるため、2FAが必要であることを認識していないサービスに誤って2FAがない「穴」を残すことはありません。
ライン
auth [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
意味: ""service=systemd-user" 条件が一致する場合は、次のauth
構成行をスキップし、そうでない場合は、その行がまったく存在しないかのように実行を続行します。
systemd-user
2つのサービス(および)などの同様のスキップを提供するには、sudo
次の手順を実行できます。
auth [success=2 default=ignore] pam_succeed_if.so service = sudo quiet
auth [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
auth sufficient pam_duo.so
最初の行が一致すると、認証を要求するサービスが既に認識されていることを確認sudo
する必要はありませんsystemd-user
。したがって、systemd-user
確認モジュールとpam_duo.so
認証モジュールの2行をスキップします。
2FAなしの認証も許可するにはsu
(たとえば)、3行目を追加します。
auth [success=3 default=ignore] pam_succeed_if.so service = su quiet
auth [success=2 default=ignore] pam_succeed_if.so service = sudo quiet
auth [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
auth sufficient pam_duo.so
など。
いつものように、PAM設定を変更するときは、次のことをお勧めします。ログアウトしないでください変更をテストした後:SSH接続を介して変更した場合は、最初の接続からログアウトするのではなく、2番目のSSH接続を開いてテストしてください。ローカルで変更する場合は、2番目のターミナルウィンドウを開き、そこからrootとしてログインするか、別の仮想コンソールに切り替えて、同じ方法でテキストモードでログインします。重大な間違いを犯したことがわかった場合は、変更を取り消すためにすでにフルroot権限でログインしているセッションが必要です。
本番システムでは、個人的に最初にログインします。第二誤って「脳より速い指」ログアウトを防ぐために、PAMを変更する前にSSHに接続してルートに切り替えます。
答え2
他の回答の情報を使って機能させることができました。まず、少なくともGNOMEでは、PAMモジュールのみを使用してログインとロック解除を区別する方法はありません。この回答。この質問に対する他の答えはpam_script
回避策としてgithubを使用することを示唆していますが、私は私のPAMスタックで他の人のgithubプロジェクトを使用したくありません.幸いなことpam_exec
に、同じことを行う組み込み関数があります。
まずスクリプトを修正してください。この回答使用pam_exec
:
#!/bin/sh
SESSION_ID=$(loginctl session-status | head -1 | cut -d' ' -f1)
if [ -z "$SESSION_ID" ]; then
exit 1
fi
if ! loginctl show-session "$SESSION_ID" | grep '^LockedHint=yes$' > /dev/null; then
exit 1
fi
# Current session is locked, return success
exit 0
必要な場所に保存し、/etc/pam.d/is-current-session-locked
それに応じて渡されたパスを変更するだけです。pam_exec
スクリプトを実行可能にします。
SESSION_ID
代わりに保存されたコマンドを使用する理由XDG_SESSION_ID
は、GNOME(少なくともRHEL 9では)が何も保存しないためですXDG_SESSION_ID
。pam_exec
コマンドの終了値が確認され、終了値自体が依存するためです。 PAMスタックロジック。
次に、for行の前に次の行を追加しましたpam_duo.so
。
auth sufficient pam_exec.so quiet /etc/pam.d/is-current-session-locked/pam_script_auth.sh
それだけで十分なので、pam_duo
処理しても何も残りません。
もちろん、他の回答で述べたように、ログインして別のセッションにルートシェルを持つことをお勧めします。この問題の解決中に何度もロックされていましたが、ルートシェルが開いていたため、そのセッションに切り替えてPAMファイルを回復してグラフィックセッションをロック解除することができました。