如何修復 SUSE Linux Enterprise Server 上的 PAM 驗證失敗問題

「PAM 身份驗證失敗」訊息並不總是意味著密碼錯誤。在 SUSE Linux Enterprise Server (SLES) 上，可插拔身份驗證模組 (PAM) 構成一個堆疊，用於檢查身分、帳戶存取權限、密碼變更和會話設定。失敗的原因可能是拼字錯誤或帳戶被停用、PAM 包含檔案損壞、LDAP 或 Active Directory 服務不可用、Kerberos 時鐘或 DNS 問題，或驗證後發生的桌面會話問題。

最穩健的解決方法是在更改配置之前，先確定是哪個服務和哪個 PAM 階段故障。本指南以 SUSE Linux Enterprise Server 15 SP7 文件為參考。如果您執行的是其他 SLES 服務套件或專用裝置映像，請在執行指令之前，請檢查對應的 SUSE 文件和已安裝的軟體套件版本。

首先，是某個服務故障，還是所有登入都發生故障？

記錄故障使用者、確切時間、主機和入口點：SSH、本機文字控制台、圖形介面登入su或應用程式。如果可能，請使用第二個已知帳戶進行測試。如果只有 SSH 失敗而控制台登入正常，/etc/pam.d/sshd則重點檢查 SSH 服務。如果本機使用者正常但目錄使用者失敗，則檢查 SSSD、LDAP、Active Directory、Kerberos、DNS 或主機的授權策略。如果控制台登入成功，但桌面拒絕使用者或返回登入畫面，則故障可能出在圖形介面會話或主目錄中，而不是密碼驗證。

排查故障時，請保持現有的 root shell 處於開啟狀態。如果您是遠端連接，請保持第二個 SSH 會話處於開啟狀態，並在修改 PAM 檔案之前確保您擁有控制台或救援存取權限。共用 PAM 檔案中的語法或控制標誌錯誤可能會阻止多個服務的新登入。

1. 閱讀關於那次失敗嘗試的日誌

SUSE 的故障排除指南建議查看系統日誌，尋找來自登入程序和 PAM 的訊息。查詢故障發生前後的一小段時間，以免無關訊息掩蓋故障原因：

sudo journalctl -b --since "15 minutes ago"

如果問題僅與 SSH 相關，請將範圍縮小到 SSH 服務端：

sudo journalctl -b -u sshd --since "15 minutes ago"

尋找服務名稱、PAM 服務名稱、模組名稱，以及訊息中是否提及auth`<service_name> `、 account`<service_name> password`、`<service_name>` 或 ` <service_name> session`。 PAMauth堆疊會檢查憑證；account檢查使用者是否有權存取該服務；session並準備使用者環境。密碼檢查成功後帳戶被拒絕，這表示的問題並非使用者未知或密碼錯誤。除非必要，否則請避免在生產系統上啟用詳細偵錯；診斷日誌可能包含帳戶名稱和其他敏感資訊。

有關本機和網路身分驗證工作流程，請參閱 SUSE 的SLES 故障排除指南。

2. 確認 SLES 可以找到用戶

在變更 PAM 之前，請檢查系統的名稱服務交換器是否可以解析該帳戶：

getent passwd user_name
id user_name

替換user_name為受影響的登入名稱。如果這些命令傳回目錄使用者沒有帳戶，則 PAM 可能運作正常，但身分查找失敗。請檢查配置的身份服務是否正在執行，主機是否可以存取該目錄，以及使用者是否被允許在此主機上登入。對於基於 SSSD 的設置，請檢查守護進程和最近的日誌：

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE 文件中指出，SSSD 同時提供 NSS 和 PAM 接口，並支援快取身分資料。如果使用者報告間歇性故障，請將本機系統的時間和 DNS 解析結果與目錄或 Kerberos 環境進行比較。 Kerberos 依賴正確的時間同步；僅憑網路連線正常並不能保證身份驗證成功。

同時檢查是否有名稱衝突。 SUSE 將本機和網路身分來源中都存在的使用者名列網路身分驗證問題的可能原因之一。在編輯 PAM 規則之前，請確認帳戶應歸屬於哪個身分來源。

3. 檢查 PAM 服務檔案和共用堆疊

SLES 將每個服務的 PAM 檔案保存在指定位置/etc/pam.d。一個服務文件（例如 `<service-file>`）/etc/pam.d/sshd通常包含共用文件，例如`<shared-file> common-auth`、common-account`<shared-file> common-password`、`<shared-file>` 和common-session`<shared-file>`。共用檔案中的錯誤行可能會影響多個服務；而一個應用程式檔案中的錯誤行可能只會影響該應用程式。

編輯前請閱讀相關文件並檢查其連結：

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

檢查模組名稱拼字錯誤、模組檔案缺失、選項錯誤、順序異常以及最近軟體包或驗證部署期間所做的變更。控制標誌至關重要：required記錄失敗但繼續執行堆疊；requisite可以立即停止；sufficient如果之前所需的模組均未失敗，則可以允許提前返回成功。切勿在不了解其模組和控制流程的情況下，從其他發行版或 SLES 版本複製 PAM 堆疊。

在進行任何變更之前，請先對目前目錄進行僅包含 root 權限的備份，並保留符號連結：

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

確認備份是否存在，並準確記錄您變更的檔案。如果所有使用者都被鎖定，請使用受支援的 SLES 恢復程序，並從已知良好的配置中恢復，而不是在登入提示字元下進行臨時操作。

4. 在 SLES 系統中，檢查 pam-config 是否管理共用文件

SUSE 提供pam-config維護全域 PAM 檔案和支援應用程式配置的功能。在新增或刪除受支援的方法時，這通常比手動編輯生成的共用堆疊更安全。首先檢查可用模組和目前的 SSSD 整合：

sudo pam-config --list-modules
sudo pam-config --query --sss

如果伺服器有意使用 SSSD 且缺少集成，SUSE 文件中sudo pam-config --add --sss提供了添加方法。但請務必在確認目錄驗證設計、檢查目前堆疊、保留備份並確保有復原路徑後再執行此操作。切勿將其作為解決所有「身份驗證失敗」的通用方案。請再次查詢配置並在第二個會話中進行測試。

一個特別危險的命令是pam-config --create`.`。 SUSE 表示，該指令會產生一個簡單的 Unix 驗證配置，並覆寫現有設定檔pam-config（這些設定檔並非由 SUSE 維護.pam-config-backup），同時保留帶有後綴的備份副本。它並非用於修復單一登入失敗的常規方法。僅當您有意重建配置並已製定恢復計劃時才應使用此命令。

如果貴組織有意手動維護 PAM 文件，請務必始終遵循此設計。 SUSE 指出，手動設定需要停用pam-config這些檔案。自訂堆疊應保留所需的會話模組，並pam_systemd.so在適用情況下將其保留為可選會話模組。

5. 分別處理 SSH、目錄和桌面問題

如果只有 SSH 拒絕該帳戶

與已知正常的 SLES 配置進行比較/etc/pam.d/sshd，並檢查 SSH 守護程式在登入失敗時的日誌。確認該帳戶已透過 SSH 本身的設定和存取控制以及 PAM 的配置。切勿為了消除錯誤而削弱 SSH 身份驗證或移除帳戶檢查。

如果只有目錄使用者失敗

使用 SSSD 狀態和日誌確認帳戶查找getent，並驗證目錄可及性、DNS、時間同步、主機註冊和使用者存取原則。如果其他目錄使用者成功，請比較受影響帳戶的群組、shell、主目錄和特定主機的存取規則。 SUSE 的身份驗證用戶端指南介紹了 YaST 管理的 SSSD 及其狀態檢查。

如果控制台登入成功但圖形會話失敗

檢查圖形登入和會話日誌、使用者主目錄的可用性、所有權、可用磁碟空間以及任何加密主目錄解鎖步驟。成功透過文字控制台登入可以有效證明密碼和基本驗證路徑有效；這會將注意力轉移到桌面會話或使用者環境。避免先刪除使用者檔案。 SUSE 的故障排除指南建議按部就班地排查桌面設定問題。

6. 在不造成系統鎖定風險的情況下驗證維修是否成功

更改後，在恢復 shell 仍然可用的情況下，開啟一個新的測試會話。使用受影響的帳戶測試受影響的服務，然後使用第二個帳戶和本機管理員帳戶進行測試。對於目錄驗證，請確認帳戶查找和服務運行狀況以及登入是否成功。再次檢查日誌中是否存在新的 PAM 錯誤，並pam-config --delete在測試完成後使用相應的選項刪除所有臨時偵錯設定。

最後，確認結果能夠解決失敗階段的問題，而不是將其隱藏起來。修復後的登入配置應該能夠驗證目標使用者身份，強制執行目標帳戶策略，並建立一個正常的會話。在驗證這些結果並記錄最終配置之前，請保留備份。

何時應該停止並使用救援模式？

如果 root 存取權限遺失、多個服務同時發生故障、共用堆疊已被覆蓋，或者您無法確定哪個設定管理員擁有這些文件，請停止進行遠端變更。 SLES 文件介紹了在無法正常登入時如何使用 root 存取權限修復配置並進入救援模式。對於受管生產系統，在重建共用身分驗證堆疊之前，請務必聯絡身分或平台團隊。

若要了解確切的 PAM 檔案結構、模組標誌、pam-config行為和復原步驟，請使用版本相符的SUSE SLES 15 SP7 PAM 指南和SUSE 常見問題指南。 PAM 堆疊是安全策略；請僅進行最小的合理更改，然後驗證存取權限和限制。