SUSE 11 SSH 账户解锁排查：pam_tally 与 passwd 到底管什么

今天在处理一个故障 SUSE 11 SSH 账户解锁方法时，我发现“账户被锁”容易把几种不同状态混在一起：密码字段被锁、登录失败次数超限、密码或账号过期，以及 SSH 或登录 Shell 本身不允许登录。它们的检查位置和恢复命令并不相同。

这篇文章把这次对话中的判断整理成一套可复用的排查思路。文中的命令是示例模板，不代表已经在某台具体 SUSE 11 主机上执行成功；处理生产主机前，应先核对目标主机、用户名和 PAM 配置。

先说结论

pam_tally 通常不是“默认装了就默认启用”。SUSE 11 是否启用登录失败锁定，要看 /etc/pam.d/ 中是否把 pam_tally.so 或 pam_tally2.so 加入了实际认证栈，以及其中的 deny、unlock_time 等参数。

passwd 也不是通常意义上的“输错几次密码后自动锁定”组件。它主要管理密码本身、密码有效期，以及管理员主动执行的密码锁定。登录失败次数锁定通常由 PAM 的 tally 模块记录和判断。

pam_tally 是否默认启用

不能因为系统中存在 pam_tally 命令或 PAM 模块，就断定它已经生效。安装介质、补丁级别、YaST 安全策略和管理员改动都可能让不同主机的 PAM 栈不同。真正有决定意义的是认证服务实际加载的 PAM 配置。

风险等级：INFO（只读）

作用： 查找 PAM 配置中是否引用了 pam_tally、pam_tally2 或其他失败锁定模块。 执行对象： 目标 SUSE 11 主机的本地控制台或已有管理员会话。 替换项： 无。 完成验证： 看到具体服务文件中的模块行，并继续核对模块参数和调用顺序。

grep -R -nE 'pam_tally(2)?\\.so|faillock' /etc/pam.d /etc/security 2>/dev/null

例如下面的配置才说明 PAM 栈明确加入了失败计数模块：

auth    required    pam_tally.so deny=5 unlock_time=900
account required    pam_tally.so

deny=5 表示失败达到 5 次后触发策略；unlock_time=900 表示锁定 900 秒。实际效果还取决于该行位于哪个服务文件、调用顺序，以及是否同时配置了 account 阶段。不要把其他发行版的默认配置直接套到 SUSE 11。

passwd 管的是哪一种锁

passwd 负责密码管理。管理员执行 passwd -l时，通常会在 /etc/shadow 的密码字段前增加 !；passwd -u则尝试移除这个密码锁定标记。

风险等级：INFO（只读）

作用： 查看密码字段状态，并检查账号和密码是否过期。 执行对象： 目标 SUSE 11 主机；替换为实际用户名。 权限要求： 使用管理员会话更稳妥。 完成验证： 记录 LK、PS 或 NP，并查看 Account expires、Password expires、Account inactive。

passwd -S <USER>
chage -l <USER>

常见的 passwd -S 状态含义是：LK 表示密码字段被锁定，PS 表示密码已设置且没有显示为锁定，NP 表示没有设置密码。LK 只能说明 shadow 密码字段的状态，不能单独证明 PAM 失败次数已超限；反过来也一样。

确认是管理员主动设置的密码锁后，才使用解锁命令：

风险等级：CAUTION（修改账号认证状态）

作用： 解锁目标账号的 shadow 密码字段。 执行对象： 已核对过的。 权限要求： root 或等效管理员权限。 影响与回退： 会改变密码认证状态；不要手工编辑 /etc/shadow。需要再次禁止密码登录时，由管理员明确执行 passwd -l。 完成验证： 再执行 passwd -S，并使用允许的认证方式进行登录验证。

passwd -u <USER>

usermod -U是另一种解锁密码字段的系统命令。除非 passwd -u 因版本或状态报错，否则没有必要把两条命令连续执行。

PAM tally 管的是失败计数

当 SSH 密码连续输错时，如果 sshd 的 PAM 栈配置了 tally 模块，流程通常是：SSH 请求进入 PAM，PAM 记录失败次数，达到阈值后按策略拒绝后续认证。这个过程不等同于 passwd -l。

先根据 PAM 配置确定使用哪个工具，不要盲目交替执行 pam_tally 和 pam_tally2。

风险等级：INFO（只读）

作用： 确认目标主机安装了哪一个 tally 查询工具。 执行对象： 目标 SUSE 11 主机。 完成验证： 记录实际存在的命令路径，并与 PAM 配置中的模块名称对应。

command -v pam_tally2
command -v pam_tally

确认 PAM 配置使用 pam_tally2.so 后，可先查询计数：

风险等级：INFO（只读）

作用： 查看目标用户当前的 PAM 失败计数。 执行对象： 目标主机；替换为实际用户名。 完成验证： 记录失败次数、最近失败时间和来源信息。

pam_tally2 -u <USER>

确认是误触发且已完成原因排查后，才考虑清零：

风险等级：CAUTION（修改 PAM 失败计数）

作用： 清除目标用户的认证失败计数。 执行对象： 已核对过的。 权限要求： root 或等效管理员权限。 影响与回退： 清零动作通常不可恢复到原计数；它不会修改密码，也不会修复过期账号、错误 Shell 或 SSH 策略。 完成验证： 再查询计数应为零或无失败记录，然后使用正确凭据测试登录。

pam_tally2 -r -u <USER>

如果 PAM 配置使用旧的 pam_tally.so，对应命令通常是：

pam_tally -u <USER>
pam_tally -r -u <USER>

上面两组命令不能仅凭“命令存在”来互换。版本、模块和计数文件格式要相互匹配。

一次排查应该按什么顺序

我会把 SSH 账户解锁拆成四个问题：

1. 是密码字段锁，还是失败计数锁

先看 passwd -S，再看 PAM 配置和 tally 计数。若 passwd -S 为 LK，优先处理 shadow 密码锁；若 shadow 未锁但 tally 计数达到阈值，处理失败计数。两者同时存在时，两个状态都要恢复。

2. 账号是否已经过期

chage -l需要单独检查。密码改正确不代表账号期限已经恢复；Account expires、Password expires 或 Account inactive 过期，仍然可能导致 SSH 拒绝。生产主机不要为了“先登录”而无条件设置永久不过期，应先确认密码策略。

3. 登录 Shell 是否允许交互登录

如果 /etc/passwd 中目标用户的 Shell 是 /sbin/nologin 或 /bin/false，清零 tally 也不能让 SSH 获得交互式 Shell。此时应先确认这是有意的服务账号限制，不能直接改成 /bin/bash。

4. SSH 本身是否允许这种登录方式

root 账号还会受到 PermitRootLogin、PasswordAuthentication、Match 条件和密钥策略影响。PermitRootLogin yes 也不等于密码认证一定可用。

容易混淆的几组命令

这也是为什么“改完密码仍然不能 SSH 登录”并不矛盾：新密码可能已经正确，但 PAM 的失败计数还没有清零；或者账号期限、登录 Shell、SSH 策略仍然阻止登录。

最后总结

pam_tally 不是 passwd 的替代品，也不能简单地说它在所有 SUSE 11 系统中默认启用。是否启用，必须以目标主机的 PAM 配置为准。

理解这类问题最有效的方式，是把“密码是否可用”和“登录是否被允许”分开看：passwd 主要维护密码及其 shadow 状态，pam_tally 维护认证失败计数，chage 管期限，SSH 和登录 Shell 决定最终的登录入口。只有确认具体状态后，才执行对应的最小恢复动作。