PAM配置错误导致SSH全局登录被拒时，应立即通过journalctl定位日志，重点检查auth[default=die]滥用、required模块无fallback及黑白名单onerr=fail等三类高危项，备份后注释MFA相关行并重载服务验证。
遇到所有用户 SSH 登录被拒、连 root 都无法进入，且确认密码正确、服务正常、网络通畅——这极大概率是 PAM 配置错误引发的认证链全局中断。它不是某个模块“不工作”，而是整个认证流程在早期就被强制终止。排查必须快、准、稳，避免误操作导致完全失联。
立刻锁定日志源头：别只看 /var/log/secure
systemd 系统上，journalctl 比传统日志更可靠，尤其对认证链中断类问题：
-
查完整登录链路：运行
journalctl -u sshd --since "5 minutes ago" | grep -i "pam\|auth\|failure"，重点找带(sshd:auth)或(sshd:account)的行，比如pam_access(sshd:auth): access denied for user root或pam_succeed_if(sshd:auth): error retrieving information about user xxx -
抓模块加载失败：执行
journalctl -b | grep -i "dlopen\|module not found\|No such file"，若出现PAM unable to dlopen(/usr/lib64/security/pam_google_authenticator.so)，说明 MFA 模块缺失或路径错误，认证直接卡在加载阶段 -
验证是否真被全拒：用另一个已有权限的账号（如通过 VNC 或控制台）执行
sudo su -c 'id' root，如果连本地 root 切换都失败，基本可断定是/etc/pam.d/system-auth或common-auth全局配置出错
聚焦三类高危 PAM 配置项
MFA 相关故障往往集中在以下三处，逐个检查：
-
auth [default=die] 规则滥用：这是最致命的。例如在
/etc/pam.d/sshd中写入auth [default=die] pam_google_authenticator.so secret=/home/${USER}/.google_authenticator，但某用户目录下没有该文件，PAM 立即返回失败并终止后续所有模块（包括密码验证），结果就是“密码对也不让进” -
required 模块返回 error 且无 fallback：如
auth required pam_faillock.so preauth silent deny=3 unlock_time=900后没跟对应auth [default=bad] pam_faillock.so authfail，会导致 preauth 阶段失败后直接拒登，不给输密码机会 -
黑白名单策略过度收紧：像
auth required pam_listfile.so item=user sense=deny file=/etc/ssh/blacklist onerr=fail，若blacklist文件权限为 644 且包含 root，或文件本身为空/损坏，onerr=fail会让整个 auth 阶段直接失败
安全回滚与快速验证
不要在线编辑，先备份再操作：
- 用控制台/VNC 登录后，立即备份：
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak.$(date +%s) - 临时禁用 MFA 行：在
/etc/pam.d/sshd中，把所有含google_authenticator、yubico、duo的行前面加#注释，保存后运行sudo sshd -t && sudo systemctl reload sshd - 验证是否恢复：新开终端尝试 SSH 登录。若成功，说明问题确在 MFA 模块；若仍失败，问题在
system-auth或password-auth等被 include 的文件中，按同样方式注释其内相关行
修复后务必做两件事
避免重启又掉坑里：
- 检查模块依赖：运行
ldd /usr/lib64/security/pam_google_authenticator.so 2>/dev/null | grep "not found"，补全缺失的库（如 libqrencode） - 验证用户环境：MFA 模块常依赖用户家目录下的密钥文件，确保
~/.google_authenticator存在、属主为该用户、权限为0600，且$HOME可读
