从PAM机制理解Linux用户认证：为什么你的passwd、ssh、su命令会‘抽风’？-编程阁

从PAM机制理解Linux用户认证：为什么你的passwd、ssh、su命令会‘抽风’？

当你第一次遇到passwd命令报错"Have exhausted maximum number of retries for service"，或者SSH密码明明正确却被拒绝，又或者su切换用户时莫名其妙失败，这些看似孤立的问题背后，其实都隐藏着一个共同的幕后黑手——Linux PAM（Pluggable Authentication Modules）认证框架。理解PAM的工作原理，就像获得了一把打开Linux认证系统黑箱的钥匙。

1. PAM架构解析：认证模块的乐高积木

PAM的核心设计哲学是模块化和可插拔。想象一下，如果把Linux认证系统比作一个乐高玩具，那么PAM就是那些可以自由组合的积木块。每个积木负责特定的认证功能，系统管理员可以根据需要将它们组装成不同的认证流程。

典型的PAM配置文件位于/etc/pam.d/目录下，每个服务都有对应的配置文件。比如sshd对应SSH服务，su对应用户切换，passwd对应密码修改。这些配置文件由一系列规则组成，每条规则定义了一个模块及其控制标志。

# 查看SSH服务的PAM配置 cat /etc/pam.d/sshd # 典型输出示例 auth required pam_sepermit.so auth substack password-auth auth include postlogin account required pam_nologin.so account include password-auth password include password-auth session required pam_selinux.so close session required pam_loginuid.so session required pam_selinux.so open

PAM模块的四种类型：

类型	作用	常见模块示例
auth	认证验证	pam_unix.so, pam_ldap.so
account	账户管理	pam_time.so, pam_access.so
password	密码管理	pam_cracklib.so, pam_pwquality.so
session	会话管理	pam_limits.so, pam_mkhomedir.so

控制标志决定了模块的执行逻辑：

required：模块必须成功，但失败不会立即返回
requisite：模块必须成功，失败立即返回
sufficient：模块成功即满足条件，不再检查后续模块
optional：模块成功与否不影响整体结果
include：包含其他配置文件中的规则

理解这些控制标志的差异，是诊断认证问题的关键。比如，当required模块失败时，用户会看到通用的认证失败信息，而不会知道具体是哪个模块导致的失败。

2. 密码修改的迷宫：passwd命令背后的PAM流程

当你在终端输入passwd命令时，触发的是一个精心设计的PAM认证链条。这个链条上的每个模块都可能成为密码修改失败的绊脚石。

2.1 密码复杂度策略的陷阱

现代Linux系统通常配置了密码复杂度检查模块，如pam_pwquality（旧版为pam_cracklib）。这些模块会强制要求密码满足一定复杂度：

# 查看密码复杂度配置 grep -E 'password.*pam_pwquality' /etc/pam.d/system-auth # 典型配置示例 password requisite pam_pwquality.so try_first_pass retry=3 minlen=12 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1

上述配置要求密码：

至少12个字符
包含至少1个数字（dcredit=-1）
包含至少1个大写字母（ucredit=-1）
包含至少1个特殊字符（ocredit=-1）
包含至少1个小写字母（lcredit=-1）

当密码不符合这些要求时，你会看到"BAD PASSWORD"警告，多次尝试后就会触发"Have exhausted maximum number of retries"错误。

2.2 历史密码检查与opasswd文件

另一个常见陷阱是历史密码检查。PAM通过pam_unix模块的remember选项可以阻止用户重复使用旧密码：

# 检查密码历史配置 grep 'pam_unix.*remember' /etc/pam.d/system-auth # 典型配置 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5

这个配置会记住最近5次密码，存储于/etc/security/opasswd文件。当你尝试重用旧密码时，系统会拒绝修改并报错。这就是为什么有时删除用户重建可以解决问题——因为新建用户没有密码历史记录。

实战技巧：当遇到密码修改被拒时，可以按以下步骤排查：

检查/etc/pam.d/system-auth中的密码策略
查看/etc/security/opasswd中的历史记录
尝试更复杂的密码组合
临时注释掉严格策略进行测试（生产环境慎用）

3. SSH认证谜团：为什么正确密码被拒绝

SSH登录失败而本地su却成功，这种看似矛盾的现象往往源于PAM与SSH配置的交互问题。

3.1 PAM与sshd_config的权限控制

SSH服务使用/etc/pam.d/sshd进行认证，但这个流程可能被/etc/ssh/sshd_config中的配置覆盖。常见冲突点：

# sshd_config中的用户限制 AllowUsers user1 user2 DenyUsers user3 AllowGroups admin DenyGroups restricted

即使PAM认证通过，如果用户不在AllowUsers列表中，SSH仍会拒绝登录。这就是为什么系统内可以su切换，但SSH登录却显示"invalid user"。

3.2 认证日志分析技巧

当SSH登录失败时，系统日志是第一个应该检查的地方：

# 查看SSH相关日志 tail -f /var/log/secure journalctl -u sshd --no-pager -n 20

关键日志信息解读：

"authentication failure"：PAM认证失败
"invalid user"：用户被sshd_config限制
"Received disconnect"：连接被主动断开
"pam_unix(sshd:auth)"：具体的PAM模块失败

案例诊断：某次SSH登录失败日志显示：

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.100 user=test Failed password for test from 192.168.1.100 port 54322 ssh2

这表明PAM认证失败，可能原因：

密码确实错误
账户被锁定（检查pam_tally2模块）
密码过期（检查chage -l test）

4. su命令的认证玄机：为什么切换用户失败

su命令的认证流程比表面看起来复杂得多，涉及多个PAM配置文件的交互。

4.1 wheel组的权限控制

传统Unix系统中，/etc/pam.d/su文件通常包含以下配置：

auth required pam_wheel.so use_uid

这表示只有wheel组成员的用户才能使用su切换到root。如果你遇到"Authentication failure"但密码正确，首先检查：

# 检查用户是否在wheel组 groups username # 检查/etc/group中的wheel组成员 grep wheel /etc/group # 检查pam_wheel配置 grep pam_wheel /etc/pam.d/su

4.2 SELinux与PAM的交互

在启用SELinux的系统上，即使PAM认证通过，SELinux策略仍可能阻止用户切换：

# 检查SELinux是否阻止su ausearch -m avc -ts recent | grep su # 临时设置SELinux为permissive模式测试 setenforce 0

4.3 多因素认证的影响

现代系统可能配置了多因素认证，导致su行为异常。检查以下配置：

# 检查是否有OTP或智能卡认证 grep pam_google_authenticator /etc/pam.d/* grep pam_sss /etc/pam.d/*

5. 高级调试技巧：像读代码一样理解PAM

要真正掌握PAM问题排查，需要学会像调试程序一样分析PAM配置。

5.1 PAM调试模式

启用PAM调试可以获取详细日志：

# 在PAM配置中添加debug选项 auth debug pam_unix.so # 查看调试日志 tail -f /var/log/secure

5.2 配置验证工具

pam_tally2用于管理登录失败计数：

# 查看用户失败计数 pam_tally2 --user=test # 重置失败计数 pam_tally2 --user=test --reset

pam_check工具可以验证PAM配置：

# 检查特定服务的PAM配置 pam_check -s sshd -a user=test

5.3 配置管理最佳实践

为避免PAM配置问题，建议：

修改前备份配置文件
使用版本控制系统管理/etc/pam.d/变更
在测试环境验证配置变更
使用配置管理工具（Ansible/Puppet）部署PAM策略

# 使用etckeeper管理/etc变更 yum install etckeeper etckeeper init etckeeper commit "Initial PAM config"

从PAM机制理解Linux用户认证：为什么你的passwd、ssh、su命令会‘抽风’？