PAM模块配置错误是SSH/RDP登录被拒的隐形原因，需通过journalctl查日志定位具体模块，核验/etc/pam.d/对应配置，用faillock等工具验证行为，并排查SELinux与文件权限干扰。
当 SSH 或 RDP 登录被拒，而密码、网络、服务状态都确认无误时，PAM 模块配置错误就是最可能的“隐形凶手”。它不报具体模块名，只甩一句 Permission denied 或直接断连，让人无从下手。排查关键不是猜，而是顺着 PAM 的执行链，逐层验证模块加载、调用逻辑和拒绝原因。
看日志：精准定位哪个 PAM 模块在拒绝
别翻 /var/log/secure，直接用 journalctl 查 systemd 日志，更及时、上下文更完整：
- 查 SSH 登录失败全过程：
journalctl -u sshd --since "10 minutes ago" | grep -i "pam\|fail\|auth"—— 关注pam_faillock、pam_access、pam_unix等模块输出，比如出现refused by pam_access就说明是/etc/security/access.conf拦住了； - 查某用户所有 PAM 行为：
journalctl _UID=$(id -u username) --since "5 minutes ago" | grep -i pam—— 可发现该用户在 SSH、sudo、甚至图形登录中是否一致被同一模块拦截； - 查模块加载失败：
journalctl -b | grep -i "dlopen\|module not found"—— 若提示unable to dlopen /lib/security/pam_faillock.so，说明模块文件缺失或路径错误，配置再对也白搭。
核配置：对照日志快速检查 /etc/pam.d/ 关键项
日志指出模块后，立刻打开对应服务的 PAM 配置文件：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- SSH 登录问题 → 打开
/etc/pam.d/sshd，重点检查auth和account段； - RDP（如 xrdp）问题 → 查
/etc/pam.d/xrdp-sesman，不是sshd； - 常见高危配置：
auth [default=die] pam_faillock.so或account required pam_access.so，若控制标志设为required或requisite且模块返回失败，整个认证链就中断； - 注意
include引用的子配置，比如auth include password-auth，要顺藤摸瓜查到/etc/pam.d/password-auth里实际生效的规则。
验行为：绕过服务直测 PAM 模块是否真生效
避免被 SSH 协议层干扰，用系统工具直接触发 PAM 认证流程：
- 测试账户锁定状态：
faillock --user username（对应pam_faillock）或pam_tally2 --user username（旧版），看是否已达锁定阈值； - 手动解锁：
faillock --user username --reset或pam_tally2 --user username --reset； - 模拟认证调用：
getent passwd username确认用户存在，getent shadow username确认密码字段非空且 shell 有效（不是/sbin/nologin）； - 临时禁用可疑模块：在
/etc/pam.d/sshd中注释掉某行（如带pam_access.so的行），重启sshd测试是否恢复登录——这是最直接的因果验证。
防干扰：留意 SELinux 与文件权限的隐性影响
即使 PAM 配置语法全对，也可能因底层环境被拦：
- SELinux 若启用，
pam_selinux.so模块可能因上下文错误拒绝会话，执行ausearch -m avc -ts recent | grep sshd查 AVC 拒绝记录； - PAM 配置文件本身权限必须是
644，/etc/security/下的策略文件（如access.conf、time.conf）也需可读，且属主为 root； -
/lib/security/或/usr/lib/security/下的.so文件若被误删、损坏或架构不匹配（如 aarch64 服务器装了 x86_64 模块），dlopen就会失败，日志里必有痕迹。
