ロックアウトせずにSLES PAMログイン失敗を診断する

「PAM認証失敗」メッセージが表示された場合、万能な解決策は存在しません。まず、どのサービスとユーザーが失敗しているかを特定し、次に該当する時刻のジャーナルを確認してください。SUSE Linux Enterprise Server (SLES) では、確認済みのグローバルPAMの問題は で修復しpam-config、個々のサービスファイルは、そのスタックに問題がある場合にのみ変更してください。テスト中は、正常に動作するrootセッションまたは管理者セッションを開いたままにしてください。PAMスタックが破損していると、新しいSSHログインやコンソールログインがブロックされる可能性があります。

最新のSLES 15 SP7セキュリティおよび強化ガイドでは、PAMを認証、アカウント、パスワード、セッションモジュールのスタックとして説明しています。この区別は重要です。正しいパスワードでも、最初のauth段階を通過しても、後でアカウントポリシーやサービス固有のルールによって拒否される可能性があるからです。一般的なエラーメッセージだけでは、どの段階でエラーが発生したかを特定することはできません。

この誤りは何を証明し、何を証明しないのか？

PAM は、アプリケーション（sshdコンソール ログインなど）と、設定された認証方法との間の仲介役となります。PAM 対応の各サービスには、 の下にファイルがあります/etc/pam.d/。サービス ファイルには、common-authやなどの SLES 共通ファイルが含まれる場合があるcommon-accountため、SSH に限定された障害は、すべてのログイン方法にわたる障害とは異なる原因を持つ可能性があります。

検証済み: SUSE のドキュメント化された SSH スタックにはpam_nologin.so、一般的な PAM ファイルが含まれています。/etc/nologin存在する場合、ドキュメント化されたモジュールは、root 以外のユーザーによるログインを拒否します。コンテキスト依存:ローカルで編集されたルール、ディレクトリ サービス、およびサードパーティの MFA モジュールは、さらにチェックを追加できます。メッセージだけでは、パスワードが間違っている、PAM ファイルが破損している、またはアカウントがロックされているとは断定できません。スタックを置き換えるのではなく、影響を受けるサービスとそのログから始めてください。

どのログイン経路でエラーが発生していますか？

一度エラーを再現し、その日時、ユーザー名、および方法（SSH、ローカルテキストコンソール、グラフィカルログイン、sudoまたは）を記録してくださいsu。管理者としてサインインできる場合は、最近のシステムメッセージを確認してください。

sudo journalctl -e

SUSEのSLESトラブルシューティングガイドでは、ログインエラーやPAMエラーについてジャーナルを確認することを特に推奨しています。ログイン試行時刻付近で、モジュール名やエラー理由（アカウント拒否、ディレクトリサービス利用不可、モジュール欠落、ファイル/権限エラーなど）を探してください。ユーザー名、ホスト名、アドレス、その他の機密情報を削除せずにログを公開しないでください。

SSH接続のみが失敗している場合は、SSHデーモンのジャーナルを確認してください。

sudo journalctl -u sshd

次に、アクセスパスを比較します。ユーザーがローカルコンソールでは認証できるのにSSH経由では認証できない場合は/etc/pam.d/sshd、SSHアクセスポリシーまたはSSH固有のモジュールに注目してください。複数のサービスが同じローカルユーザーを拒否する場合は、共有common-*ファイルを調べます。1人のユーザーのみが認証に失敗した場合は、システム全体の認証を変更する前に、アカウントの状態とパスワードを確認してください。

これはローカルアカウントですか、それともネットワークIDですか？

ローカルユーザーの場合は、まずユーザー名、キーボードレイアウト、Caps Lock を確認してください。認証情報のリセットが必要な場合は、/etc/shadow手動で編集するのではなく、YaST ユーザーおよびグループ管理などの管理者承認済みのパスワードツールを使用してください。すべての非ルートユーザーが SSH 経由で拒否された場合は、PAM を変更する前に、計画メンテナンス ファイルが/etc/nologin存在するかどうかを確認してください。メンテナンス ブロックが古いことが確認され、かつ権限がある場合にのみ、そのファイルを削除してください。

LDAP、Active Directory、またはその他のディレクトリベースのユーザーの場合、別のサーバーで有効なパスワードがあっても、このSLESホストがIDプロバイダにアクセスできることを証明するものではありません。SUSEは、考えられる原因として、ネットワークとDNSの問題、Kerberosクロックのずれ、PAMルールの設定ミス、ホストアクセスポリシー、および利用できないホームディレクトリを挙げています。別のドメインユーザーがログインできるかどうか、また影響を受けているユーザーが別のホストにログインできるかどうかをテストしてください。次に、設定されているIDサービスとサーバーの接続性を確認してください。

ホストがSSSDを使用している場合、そのサービスと、PAMがSSSDを使用するように構成されているかどうかを確認します。

systemctl status sssd
sudo pam-config --query --sss

SSSD はユーザー情報をキャッシュすることができ、ディレクトリに一時的にアクセスできない場合でも認証を許可する場合がありますが、その動作は構成とキャッシュされた認証情報に依存します。したがって、キャッシュが古い、または存在しないことは可能性の一つであり、結論ではありません。キャッシュをクリアしたりモジュールを変更したりする前に、DNS、Kerberos の時刻同期、ディレクトリへのアクセス可能性、および SSSD ログを確認してください。ID プロバイダが「アカウントがロックアウトされました」または「アカウントが無効になりました」と報告した場合は、ディレクトリ管理者にそのアカウントのポリシーを確認してもらってください。PAM は決定を報告しているだけで、必ずしも決定を作成しているわけではありません。

確認済みのPAM構成の問題をどのように修復すればよいですか？

サービス固有のファイルと、それに含まれる共有ルールを確認してください。

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

SLES では、pam-configグローバルファイルは の下に保持されます/etc/pam.d/common-*。 などの個々のサービスファイルは/etc/pam.d/sshd個別に保持されます。 意図的に無効にしていない限り、生成された共通ファイルを手動で編集しないでくださいpam-config。 このホストが SSSD を使用するはずであり、SSSD PAM ルールが欠落していることを確認した場合は、SUSE のドキュメントをsudo pam-config --add --sss参照してルールを追加してください。 SSSD 自体が構成され、実行されていることを確認した後でのみ使用し、作業中の管理セッションが開いたままの状態で新しいログインをテストしてください。

よくある誤解ですが、これpam-config --createは無害な修復コマンドだと考えられがちです。SUSEによると、このコマンドは基本的なUnix認証構成を作成し、管理対象外の既存ファイルを上書きしてバックアップコピーを保持します。そのため、カスタムMFAやディレクトリ認証の動作が削除される可能性があります。一般的な復旧手順として実行しないでください。サービスファイルのタイプミスについては、信頼できるバックアップからそのサービスの既知の正常なバージョン対応構成を復元するか、組織の変更プロセスに従って問題のある特定の行を変更してください。

修理が完了したことをどのように確認できますか？

元のルートセッションまたは管理者セッションは開いたままにしておきます。失敗したサービスと同じサービス（新しいSSH接続など）を介して別のセッションを開始し、影響を受けたアカウントをテストします。ジャーナルに同じPAM拒否が記録されなくなり、別の設定済み認証方法が引き続き機能することを確認します。失敗が続く場合は、正確なタイムスタンプ、サービス、PAMモジュール名、および関連する匿名化されたログ行を取得します。これらの詳細は、一般的な「認証失敗」メッセージよりも有用です。

公式資料

• SUSE SLES 15 SP7 管理ガイド：よくある問題とその解決策— ローカルおよびネットワークログインのトラブルシューティング。
• SUSE SLES 15 SP7 セキュリティおよび強化ガイド: PAM による認証— PAM ステージ、SSH スタック、およびpam-config。
• SUSE SLES 15 SP7: YaST を使用した認証クライアントの設定— SSSD の状態とキャッシュの動作。
• SUSE SLES 15 SP7: OpenSSH を使用したネットワーク操作のセキュリティ確保— sshd ジャーナル メッセージの表示。