PAM 認証スタック変更の本番適用｜ロックアウトリスク回避と切り戻し手順

なぜ PAM 変更でロックアウトが起きるのか

PAM（Pluggable Authentication Modules）は Linux の認証処理を「スタック」と呼ばれる連鎖ルールで制御します。/etc/pam.d/ 配下の各ファイルが、sshd・sudo・login といった個々のサービスごとに「どのモジュールをどの順序で、どの制御フラグで呼び出すか」を定義します。

ロックアウトが起きやすいのは、この「スタック」の性質を見落としたときです。制御フラグ required と requisite の違い、pam_faillock や pam_tally2（非推奨）の挿入位置、pam_unix への依存順序——いずれか一箇所でも誤ると、設定ファイルを保存した瞬間から新規ログインが通らなくなります。SSH セッションを保持していても、sudo が使えなければ復旧作業自体が詰まります。

月次 CVE 対応の文脈では、libpam 本体や pam_unix・pam_krb5 等のモジュールパッケージを更新した後、パッケージが設定ファイルのひな型（.rpmnew / .dpkg-new）を置くケースがあります。これをそのままマージすると既存カスタマイズが上書きされ、想定外の認証フローになる点も見落としがちです。

変更前に必ず済ませる準備

セッションの確保

PAM 設定を変更する前に、root 権限を持つ端末セッションを 2 つ以上開いておきます。1 つは変更作業用、もう 1 つは「設定が壊れたときの脱出路」です。既存セッションは PAM 再評価を受けないため、作業中に新規ログインが失敗し始めても既存セッションから操作を続けられます。

# 作業前に別ターミナルから root セッションを確保
ssh -i ~/.ssh/id_ed25519 root@target-host
# 接続できたら以下で保持確認
who

現行設定のバックアップ

変更対象のファイルと、影響が連鎖しうる共通スタック（common-auth・system-auth など）を丸ごとバックアップします。タイムスタンプ付きディレクトリに退避しておくと切り戻し時に迷いません。

BACKUP_DIR="/root/pam-backup-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"
cp -a /etc/pam.d/ "$BACKUP_DIR/"
cp -a /etc/security/ "$BACKUP_DIR/"   # faillock.conf, limits.conf 等

構文チェックツールの確認

Red Hat 系では authselect、Debian 系では pam-auth-update が推奨される管理レイヤーです。これらを経由せずに直接 pam.d を編集する場合、構文誤りを事前に検出できるツールがないため、テスト環境での動作確認が必須になります。pamtester パッケージを導入すると、サービスを停止せずに認証フローを手動でテストできます。

# pamtester での疎通確認（例：sudo サービスで testuser のパスワード認証）
pamtester sudo testuser authenticate

本番適用の手順

変更内容の差分管理

設定変更は Git や diff で差分を残します。直接 vi で編集する場合も、保存直前に別ウィンドウで diff を確認する習慣をつけると、意図しない行削除を防げます。

# 変更前後の差分を記録
diff /etc/pam.d/sshd "$BACKUP_DIR/pam.d/sshd"

段階適用：1 サービスずつ確認する

複数サービスの PAM 設定をまとめて変更するのは避けます。sshd → sudo → login の順に 1 ファイルずつ変更し、その都度「新規セッションでの疎通確認」を挟みます。common-auth（Debian 系）や system-auth（RHEL 系）を変更すると多数のサービスに一斉に影響するため、これらを触る場合は特に慎重にテスト環境で先行検証を済ませておきます。

pam_faillock 挿入時の注意点

CVE 対応で pam_faillock を新規に挿入するケースでは、preauth（認証前）と authfail（認証失敗後）の 2 行をペアで書く必要があります。片方を欠くとカウンタが正しく機能しないか、あるいは正常ログインでもアカウントがロックされます。

# /etc/pam.d/system-auth（RHEL 系の想定例）
auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent deny=5 unlock_time=900
auth        sufficient    pam_unix.so nullok
auth        [default=die] pam_faillock.so authfail deny=5 unlock_time=900
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

上記は想定例です。実際の環境ではディストリビューションのバージョンやカスタマイズ内容によって順序が異なります。/etc/security/faillock.conf に設定値をまとめる方式（RHEL 8 以降の推奨）も確認してください。

変更後の検証手順

変更を保存したら、現行セッションを維持したまま以下を確認します。

• 新規 SSH ログイン：別端末から鍵認証・パスワード認証の両方で接続できるかを確認します。
• sudo の動作：一般ユーザーから sudo -l と sudo whoami を実行し、パスワードプロンプトと昇格が正常か確認します。
• faillock カウンタ：意図的に誤パスワードを入力してカウンタが増加し、faillock --user 対象ユーザー で記録されることを確認します。その後 faillock --reset --user 対象ユーザー でリセットできることも確認します。
• ログ確認：journalctl -u sshd -n 50 や /var/log/auth.log に予期しないエラーが出ていないかを確認します。

よくあるつまずきとして、pam_unix に try_first_pass を付け忘れたために二重でパスワードを求められるケースや、pam_faillock の deny 値が 0 のままで即座にロックされるケースがあります。ログに pam_faillock: user unknown や authentication failure が連続して出る場合は設定の見直しが必要です。

切り戻し手順

新規ログインが通らない・sudo が機能しないといった障害を検知した場合、保持している root セッションから即座にバックアップを復元します。

# バックアップから pam.d と security を復元
BACKUP_DIR="/root/pam-backup-YYYYMMDD-HHMMSS"   # 実際のパスに置き換える
cp -a "$BACKUP_DIR/pam.d/" /etc/pam.d/
cp -a "$BACKUP_DIR/security/" /etc/security/

# 復元後、新規端末から SSH 接続できるか確認
# ファイルコピー後は即時反映されるため sshd 再起動は不要なケースが多いが
# pam_systemd 等を変更した場合は systemctl daemon-reexec を検討する

PAM はほとんどの場合、ファイルを元に戻すだけで即時反映されます。ただし systemd-logind が関与する設定（pam_systemd・pam_systemd_home）を変更した場合は、systemctl daemon-reexec または該当サービスの再起動が必要になることがあります。

万が一 root セッションも失われた場合は、クラウド環境であればシリアルコンソール・レスキューモード、オンプレミスであれば GRUB の rd.break を使ったシングルユーザーモードでの復旧になります。この手順はあらかじめ手順書に記載しておき、オペレーション担当が独力で実施できる状態にしておくことが重要です。

2026 年現行環境での注意点

authselect（RHEL 8以降）と pam.d の直接編集の競合

RHEL 8・Rocky Linux 8 以降では authselect が PAM 設定の管理レイヤーとして採用されています。authselect を使って設定を変更した後に手動で pam.d を直接編集すると、次回 authselect apply-changes を実行した際に手動変更が上書きされます。カスタムプロファイルを作成して管理するか、authselect の使用を完全に停止してから手動管理に統一するか、方針を明確にしておく必要があります。

pam_tally2 の廃止

pam_tally2 は多くのディストリビューションで非推奨・削除済みです。RHEL 7 以前から移行してきた設定ファイルにこのモジュールが残っている場合、RHEL 8/9 や Ubuntu 22.04 以降では認証が通らなくなります。pam_faillock（RHEL 系）または pam_faildelay + pam_abl の組み合わせへの移行が現行標準です。

sssd・FreeIPA・Azure AD 連携環境

sssd を経由して FreeIPA・LDAP・Azure AD Kerberos 認証を行っている環境では、pam_sss モジュールの位置がローカル認証と干渉しやすいです。pam_faillock をローカルユーザーにのみ適用したい場合は、pam_succeed_if で UID 範囲やグループを絞り込むか、sssd 側の pam_account_mgmt との整合を確認します。

CVE 対応パッケージ更新後の .rpmnew / .dpkg-new 確認

月次 CVE パッチとして pam パッケージ本体を更新した際、パッケージ側が新しいデフォルト設定ファイルを .rpmnew や .dpkg-new として配置することがあります。更新後は以下で確認します。

# RHEL 系
find /etc/pam.d /etc/security -name "*.rpmnew" -o -name "*.rpmsave"

# Debian 系
find /etc/pam.d /etc/security -name "*.dpkg-new" -o -name "*.dpkg-old"

見つかった場合は差分を確認し、セキュリティ修正に相当する変更のみを現行ファイルに手動でマージします。ファイルごとそのままリネーム適用すると既存カスタマイズが失われます。