診斷 SLES PAM 登入失敗問題，避免被鎖定

「PAM 驗證失敗」訊息並沒有提供通用的解決方案。首先要確定是哪個服務和使用者發生故障，然後檢查對應時間點的日誌。在 SUSE Linux Enterprise Server (SLES) 上，如果已確認有全域 PAM 問題，請透過 `pamconfig` 指令進行修復pam-config，僅當某個服務的堆疊出現問題時才修改該服務的設定檔。測試時，請保持一個可用的 root 使用者或管理員會話處於開啟狀態；損壞的 PAM 堆疊可能會阻止新的 SSH 和控制台登入。

目前的 SLES 15 SP7 安全性增強指南將 PAM 描述為由身份驗證、帳戶、密碼和會話模組組成的堆疊。這種區分至關重要：即使密碼正確auth，也可能在後續階段被帳戶原則或特定於服務的規則拒絕。僅憑通用的錯誤訊息無法確定是哪個階段失敗了。

這個錯誤證明了什麼？它又不能證明什麼？

PAM 在應用程式（例如sshd控制台登入）和已設定的身份驗證方法之間進行協調。每個支援 PAM 的服務都有一個 PAM 檔案/etc/pam.d/。此服務文件可能包含 SLES 通用文件，例如 `<service-file>`common-auth和common-account`<service-file>`，因此，SSH 獨有的故障原因可能與所有登入方法的故障原因不同。

已驗證： SUSE 文件中記錄的 SSH 協定堆疊包含pam_nologin.so常用的 PAM 檔案。如果/etc/nologin存在，文件中記錄的模組會拒絕 root 使用者以外的其他使用者登入。上下文相關：本地編輯的規則、目錄服務和第三方 MFA 模組可以添加更多檢查。僅憑訊息無法確定：密碼錯誤、PAM 檔案損壞或帳戶已被鎖定。應先檢查受影響的服務及其日誌，而不是替換整個協定堆疊。

哪個登入路徑失敗了？

請重現故障一次，並記錄時間、使用者名稱和登入方式：SSH、本機文字控制台、圖形介面登入sudo等su。如果您可以以管理員身分登入，請檢查最近的系統訊息：

sudo journalctl -e

SUSE 的 SLES 故障排除指南特別建議檢查日誌中的登入和 PAM 錯誤。在嘗試登入的確切時間附近尋找模組名稱或錯誤原因，例如帳戶被拒絕、目錄服務不可用、模組缺失或檔案/權限錯誤。切勿在未刪除使用者名稱、主機名稱、地址和其他敏感資訊的情況下公開分享日誌。

準備一個根終端，使用 journalctl -e 檢查最近的系統日誌條目。 — 使用登入失敗時間附近的系統日誌尋找 PAM 和登入過程訊息。

如果只有 SSH 連線失敗，請檢查 SSH 守護程式的日誌：

sudo journalctl -u sshd

準備一個 root 終端，使用 journalctl -u sshd 讀取 SSH 守護程式日誌。 — 如果故障僅在 SSH 驗證期間發生，請檢查 sshd 日誌。

然後比較訪問路徑。如果使用者可以透過本機控制台進行身份驗證，但無法透過 SSH 進行身份驗證，則專注於檢查/etc/pam.d/sshdSSH 存取原則或 SSH 特定模組。如果多個服務拒絕同一本機使用者的訪問，請檢查其共用common-*檔案。如果只有一個使用者失敗，請在變更系統級身份驗證之前驗證帳戶狀態和密碼。

這是本機帳戶還是網路身分？

對於本機用戶，請先檢查用戶名、鍵盤佈局和大小寫鎖定鍵。如果需要重設憑證，請使用管理員批准的密碼管理工具（例如 YaST 使用者和群組管理工具），而不是/etc/shadow手動編輯。如果所有非 root 使用者都無法透過 SSH 訪問，請在更改 PAM 之前檢查是否存在計劃維護文件/etc/nologin；僅當確認維護區塊已過期且您已獲得授權時，才能將其刪除。

對於 LDAP、Active Directory 或其他基於目錄的用戶，在其他伺服器上使用有效密碼並不能證明此 SLES 主機可以存取身分提供者。 SUSE 列出了網路和 DNS 問題、Kerberos 時鐘漂移、PAM 規則配置錯誤、主機存取原則以及主目錄不可用等可能的原因。測試其他網域使用者是否可以登入，以及受影響的使用者是否可以登入其他主機。然後檢查配置的身份服務和伺服器連線。

當主機使用 SSSD 時，檢查其服務以及 PAM 是否已配置為使用該服務：

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

終端機顯示唯讀的 PAM SSSD 設定查詢和 SSSD 服務狀態指令。 — 檢查 SSSD 是否包含在 PAM 中，以及在網域支援的使用者無法進行身份驗證時 SSSD 是否正在執行。

SSSD 可以快取使用者訊息，並在目錄暫時無法存取時允許身份驗證，但此行為取決於其配置和快取的憑證。因此，緩存過期或缺失只是一種可能性，而非最終結論。在清除任何快取或更改模組之前，請檢查 DNS、Kerberos 時間同步、目錄可及性以及 SSSD 日誌。如果身分提供者報告“帳戶已鎖定”或“帳戶已停用”，請目錄管理員檢查該帳戶的策略；PAM 只是報告決策，並非一定由 PAM 制定。

如何修復已確認的PAM設定問題？

檢查特定於服務的文件及其包含的共用規則：

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

終端命令檢查 sshd PAM 服務文件中的 auth、account、password 和 session 條目。 — 在變更通用驗證規則之前，請檢查 sshd 的特定服務 PAM 堆疊。

在 SLES 系統中，pam-config全域檔案保存在 `<path>` 下/etc/pam.d/common-*；各個服務檔案（例如`<service-file> /etc/pam.d/sshd`）則是單獨維護。除非您已明確停用某些公開文件，否則請勿手動編輯產生的公開文件pam-config。如果您確認此主機應使用 SSSD 但缺少其 SSSD PAM 規則，請參考 SUSE 文件sudo pam-config --add --sss新增這些規則。僅在確認 SSSD 本身已配置並運行後才可使用此方法，然後在目前管理工作階段保持開啟的情況下測試新的登入。

一個常見但危險的誤解是，這pam-config --create是一個無害的修復命令。 SUSE 表示，它會建立一個基本的 Unix 驗證配置，並覆寫它不管理的現有文件，但會保留備份副本。這可能會移除自訂 MFA 或目錄驗證功能。請勿將其作為通用恢復步驟運行。如果是服務文件中的拼字錯誤，請從可信任備份中還原該服務已知良好且版本相符的配置，或依照貴組織的變更流程修改特定的錯誤行。

如何確認維修完成？

保持原有的 root 或管理員會話處於開啟狀態。透過失敗的相同服務（例如新的 SSH 連線）啟動第二個會話，並測試受影響的帳戶。確認日誌中不再記錄相同的 PAM 拒絕，並且其他已設定的身份驗證方法仍然有效。如果故障仍然存在，請擷取確切的時間戳記、服務、PAM 模組名稱以及相關的已脫敏日誌行；這些詳細資訊比通用的「驗證失敗」訊息更有用。