PAMモジュールで多要素認証を本番に適用する｜設定ミスのリスク管理とロールバック手順

PAM多要素認証を本番に持ち込む前に理解しておくこと

PAM（Pluggable Authentication Modules）は、Linuxの認証処理をモジュールとして差し替えられる仕組みです。SSHやsuをはじめとする多くのサービスが内部でPAMを呼び出しており、/etc/pam.d/以下の設定ファイルを変更するだけで認証フローを大きく変えられます。

多要素認証（MFA）を本番サーバーへ適用する際、最大のリスクは「認証が通らなくなったとき、別経路でログインできるかどうか」です。テスト環境ではすんなり動いたのに、本番でPAMスタックを変更した途端に全SSHセッションが弾かれるという事故は珍しくありません。requiredとsufficientの違いを意識せずに設定を書いたり、TOTPトークンのユーザーごとのセットアップが完了していない状態で適用したりすることが主な原因です。

本記事では、TOTPベースのMFAをSSHへ適用する実務的な手順を、段階的展開・検証・ロールバックまで含めて解説します。対象ディストリビューションはUbuntu 22.04/24.04およびRHEL系9系（Rocky Linux・AlmaLinux含む）です。

本番適用前に必ず用意するロールバック経路

PAM設定の変更は、適用した瞬間に既存のセッションには影響しません。しかし新たに張るセッションはすべて変更後の設定で認証されます。このため、設定ミスがあれば次のログインから締め出されます。

現場で確認されている緊急退路は主に3パターンです。

• コンソール直接アクセス：クラウドであればシリアルコンソールやSystems Manager Session Managerを事前に有効にしておく。物理サーバーであればiDRAC・iLO・IPMIの接続情報を事前に確認する。
• 別SSHポートの維持：PAMスタックを変更しない別ポートのsshdインスタンスを一時的に立てておき、ロールバック完了後に閉じる。
• 設定ファイルのバックアップ：変更前の/etc/pam.d/sshdと/etc/ssh/sshd_configを必ず別ディレクトリにコピーしておく。

ロールバック経路が1本も確保できない状態での本番変更は、どれほど小さな修正であっても避けるべきです。この前提を確認してから次のステップへ進みます。

pam_google_authenticatorによるTOTP設定の手順

TOTPを実現するモジュールとして最も普及しているのがpam_google_authenticatorです。Debian系ではlibpam-google-authenticatorパッケージ、RHEL系ではgoogle-authenticator-libpamパッケージとして提供されています。

インストール後、各ユーザーがgoogle-authenticatorコマンドを実行してシークレットキーとリカバリーコードを生成します。このコマンドを実行していないユーザーは、PAMスタック設定次第で認証を通過できなくなるため、全ユーザー分のセットアップ完了を確認してから次のステップへ進むことが重要です。

/etc/pam.d/sshdに追加する行は以下の形式です。

auth required pam_google_authenticator.so nullok

nullokオプションを付けると、~/.google_authenticatorファイルが存在しないユーザーはOTPなしで認証を通過できます。段階的展開の初期フェーズではこのオプションを付けておき、全ユーザーのセットアップ完了を確認してからnullokを外すという二段階の切り替えが現場では有効です。

あわせて/etc/ssh/sshd_config側でも変更が必要です。

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

公開鍵認証とOTPを組み合わせる場合はAuthenticationMethodsで両方を指定します。公開鍵のみで通過させたい管理アカウントがあれば、Match Userブロックで個別にAuthenticationMethods publickeyを上書きする方法が取られます。

段階的展開と動作確認の進め方

PAM設定を本番へ適用するとき、いきなり全サーバーに展開するのは避けるべきです。1台の非クリティカルなサーバーで先行適用し、複数のユーザーアカウントで正常に認証が通ることを確認してから横展開するパターンが安全です。

動作確認の際は、既存のセッションを切らずに別ターミナルから新規接続を試みることが基本です。既存セッションを閉じてしまうと、設定ミスがあった場合にリカバリー経路が1本減ります。

確認すべき項目を整理すると次のとおりです。

• TOTPセットアップ済みユーザーで公開鍵＋OTPの2段階認証が通るか
• nullok指定中、セットアップ未済みユーザーが公開鍵のみで通過できるか
• sudoやsuなど他のPAMサービスに意図しない影響が出ていないか
• sshdのJournalログ（journalctl -u sshd -f）に認証失敗の記録がないか

sshdのリロードはsystemctl reload sshdで行います。restartは既存セッションを切断するため、設定変更時はreloadを優先します。Ubuntu 22.04以降ではssh.serviceとssh.socketの両方が存在するケースがあり、どちらが実際の接続を担っているかをあらかじめ確認しておく必要があります。

設定ミス発生時のロールバック手順

仮にSSHで新規接続できなくなった場合、コンソール経由でログインしてバックアップから設定を戻します。

手順の骨格は次のとおりです。コンソールでrootまたはsudoユーザーとしてログインし、バックアップしておいた/etc/pam.d/sshdと/etc/ssh/sshd_configを元の場所へ上書きコピーします。その後systemctl reload sshdを実行し、別ターミナルからSSH接続を試みて復旧を確認します。

クラウド環境でコンソールが使えない場合は、ユーザーデータスクリプトやSSMのRun Commandを経由して設定ファイルを差し替えるアプローチが取られます。AWSであればaws ssm send-commandでシェルスクリプトを実行し、GCPであればgcloud compute ssh --tunnel-through-iapでIAPトンネル経由のアクセスが可能です。ロールバック手順そのものより、ロールバック経路を事前に検証しておくことのほうが重要です。

また、ansibleやterraformでPAM設定を管理している場合は、ロールバック用のプレイブック・モジュールをあらかじめ用意しておき、適用の逆順で実行できる状態にしておくと復旧時間を大幅に短縮できます。

2026年の現行環境で押さえておくべき差分

2026年時点でのLinux本番環境では、いくつかの変化が運用上の考慮点として浮上しています。

Ubuntu 24.04のsshd変更：Ubuntu 24.04 LTSではOpenSSH 9.x系が採用され、ChallengeResponseAuthenticationディレクティブが廃止されました。同等の設定はKbdInteractiveAuthentication yesで行います。既存の設定をそのままコピーするとsshd -tの構文チェックで警告が出るため、移行前に確認が必要です。

RHEL 9系でのpam_pwqualityとの競合：Rocky Linux 9・AlmaLinux 9ではpamの設定スタックにデフォルトでpam_pwqualityが組み込まれています。MFA用のモジュールを追加する際、スタックの順序が意図せず変わるケースが報告されており、/etc/authselect/の管理下にある設定ファイルを直接編集するとauthselectの管理と競合します。RHEL系ではauthselectコマンド経由でMFAプロファイルを適用する方法が現行の推奨手順です。

ハードウェアキーの普及：FIDO2/WebAuthnに対応したハードウェアセキュリティキーをSSH認証に使うpam_u2f（libpam-u2fパッケージ）の採用事例が増えています。TOTPと比べてフィッシング耐性が高く、エンタープライズのゼロトラスト移行に伴う採用が進んでいます。TOTPで構築した既存の仕組みから移行する場合、ユーザーへのデバイス配布・登録手順の整備が別途必要になります。

sssdとの統合：Active DirectoryやLDAPとsssdで連携しているサーバーでは、PAMスタックがsssdによって部分的に管理されています。/etc/pam.d/sshdへの直接変更がsssdの認証フローと干渉することがあるため、sssdのpam_cert_authやtry_cert_auth設定との整合を確認してから変更を加えることが求められます。

PAM多要素認証の本番適用は、コマンド数行の変更であっても影響範囲が広く、準備と検証に相応の時間をかける価値があります。段階的展開・ロールバック経路の確保・ディストリビューション固有の差分把握、この3点を事前に押さえることで、本番でのトラブルは大幅に抑えられます。