journalctl日志比/var/log/secure更准，重点用三条命令查PAM错误：查sshd登录链路、查某用户所有PAM活动、查模块加载失败，并结合/etc/pam.d/配置与SELinux干扰排查。
直接看 journalctl 日志里的 PAM 错误，比翻 /var/log/secure 更准——尤其在 systemd 系统上，日志更全、时间更准、服务上下文更清晰。
重点盯这几个 journalctl 命令
不用记太多，掌握以下三条就能覆盖 90% 的 PAM 认证失败场景：
-
查 SSH 登录失败的完整链路：
journalctl -u sshd --since "1 hour ago" | grep -i "pam\|failure\|auth"不只看“Failed password”，还要抓 pam_unix、pam_faillock、pam_access 等模块输出，它们常带具体拒绝原因（比如 “refused by pam_access” 或 “user not allowed”） -
查某用户所有 PAM 相关活动：
journalctl _UID=$(id -u username) --since "30 minutes ago" | grep -i pam这能绕过服务名限制，看到 lightdm、vsftpd、sudo 等不同服务调用 PAM 时的真实行为，适合排查“同一个用户在不同服务下有的能登、有的不能登”的问题 -
查 PAM 模块加载失败（如 unable to dlopen）：
journalctl -b | grep -i "dlopen\|pam.*so\|module not found"这类错误往往不报在 auth 阶段，而是在 session 或 account 阶段启动时就失败了，比如 lightdm 启动时报 pam_kwallet.so 找不到，或 vsftpd 报 pam_userdb.so 加载异常
看懂关键字段：别被日志绕晕
journalctl 输出里真正有用的不是整行，而是几个固定位置的字段：
-
模块名 + 阶段：比如
pam_unix(sshd:auth)表示 sshd 服务在 auth 阶段调用了 pam_unix；pam_faillock(sshd:account)表示在 account 阶段触发了锁定检查 -
返回状态：常见有
error、ignore、success，但注意有些模块即使返回 success，也可能因控制标志（如 [success=done]）跳过后续模块，造成“看似成功实则中断” -
具体提示文本：像
authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.200 user=root这种，包含了来源 IP、目标用户、执行者 UID、终端类型，是定位异常登录的核心线索
配合 /etc/pam.d/ 文件交叉验证
journalctl 告诉你“哪里错了”，但要搞清“为什么错”，得立刻打开对应服务的 PAM 配置：
- SSH 登录失败 → 看
/etc/pam.d/sshd - 图形界面进不去 → 看
/etc/pam.d/lightdm和/etc/pam.d/lightdm-greeter - vsftpd 报 530 → 看
/etc/pam.d/vsftpd，特别注意是否启用了pam_userdb且数据库文件路径/权限是否正确 - sudo 提权失败 → 看
/etc/pam.d/sudo，留意是否有pam_wheel或pam_listfile拦截
重点检查三类问题：模块路径是否存在（ls /lib/security/pam_*.so）、行末是否多空格导致语法解析失败、control flag（如 required/requisite/sufficient）是否与业务逻辑冲突。
快速排除 SELinux / AppArmor 干扰
如果 journalctl 明确报了 avc: denied 或 audit 字样，大概率是安全模块拦截了 PAM 调用：
- 临时放行测试：
sudo setenforce 0（SELinux）或sudo aa-disable /usr/sbin/sshd（AppArmor），再试登录；若恢复正常，说明策略过严 - 查详细拒绝记录：
sudo ausearch -m avc -ts recent | audit2why（SELinux）或sudo dmesg | grep -i avc - 不要长期关闭，应根据 audit 日志生成自定义策略：
sudo audit2allow -a -M mypamfix，再sudo semodule -i mypamfix.pp
