Linux如何限制SSH登录尝试次数 配合pam_tally2使用

配置了pam_tally2却发现账号根本锁不住？这几乎是每个初次接触PAM认证模块的管理员都会踩的坑。问题根源往往不在于模块本身，而在于配置文件的加载顺序上。

为什么 pam_tally2 无法生效？检查模块加载和配置顺序

绝大多数情况下，pam_tally2失效的罪魁祸首是PAM配置顺序错误。这里有个关键认知：SSH登录认证走的是独立的/etc/pam.d/sshd文件，而不是通用的system-auth或common-auth。即便你修改了后者，sshd服务也不会自动继承这些规则，除非在sshd文件中显式地include它们。

所以，正确的操作路径是直接编辑/etc/pam.d/sshd文件。并且，修改的位置至关重要——必须在认证段（auth）的开头插入pam_tally2的配置行，而且要确保它位于pam_unix.so（负责实际密码验证的模块）之前。如果顺序反了，失败计数逻辑就永远不会被触发。

来看一个典型的错误配置：

auth [default=ignore] pam_tally2.so deny=3 unlock_time=300

这行配置如果被放在了pam_unix.so后面，会发生什么？认证流程会先执行密码验证，一旦密码错误，pam_unix.so直接就返回认证失败了，后续的pam_tally2模块根本没有机会执行计数操作。

正确的做法应该是这样：

在/etc/pam.d/sshd文件的顶部auth段落，紧贴第一个auth指令之前，插入如下配置：

auth [default=die] pam_tally2.so deny=3 unlock_time=300 even_deny_root

这里有几个参数值得注意：default=die表示当该模块失败（即达到失败次数）时，立即终止整个PAM栈的认证流程；even_deny_root则确保root用户也在限制之列。

最后，还有一个前置检查必不可少：确认你的系统是否已经启用了pam_faillock。在新版的RHEL/CentOS 7及以上系统中，pam_faillock已经取代pam_tally2成为默认的失败计数模块。如果两个模块同时启用，很可能会产生冲突，导致规则失效。

deny=3 是指 3 次失败后锁定，还是累计到 3 次？

对deny=3这个参数的理解，直接关系到锁定的时机。它表示的是“第3次失败后立即拒绝后续登录”，而不是“累计达到3次失败后才开始锁定”。

举个例子就清楚了：用户第一次输入错误密码，计数器变为1；第二次错误，计数器变为2；当第三次尝试依然错误时，计数器达到3，此时pam_tally2模块会立即返回认证失败。PAM认证流程因此中断，后续的pam_unix.so等模块都不会再执行，用户直接被拒之门外。

关于计数器的几个关键细节：

• 计数器是针对每个用户独立生效的，数据记录在/var/log/tallylog这个二进制文件中（所以无法直接用cat命令查看）。
• 使用pam_tally2 --user 命令可以查询指定用户的当前失败计数；使用pam_tally2 --user --reset则可以手动将计数器清零。
• unlock_time=300意味着账户在锁定300秒后会自动解锁。如果不设置这个参数，则需要手动执行reset操作来解锁，或者使用no_lock_time参数来禁用自动解锁功能。
• 特别注意：deny的值不能设置为0，在某些系统版本中，这会导致模块行为异常，甚至直接被跳过。

SSH 登录失败但 pam_tally2 不计数？排查 PAM 调用链和 SELinux 干预

另一种让人头疼的情况是：明明密码输错了，但pam_tally2 --user xxx查出来的计数却始终是0。这通常意味着pam_tally2模块根本就没有被调用到。

最常见的原因，是SSH服务本身的认证方式配置。如果sshd_config中设置了PasswordAuthentication no，或者优先使用公钥认证（PubkeyAuthentication yes），那么整个密码认证的流程分支都不会被触发，pam_tally2自然也就没有计数的机会。

遇到这种情况，可以按照以下步骤排查：

1. 首先确认/etc/ssh/sshd_config中PasswordAuthentication yes是启用的（很多系统为了安全，默认会关闭密码登录）。
2. 使用sshd -T | grep -i auth命令，查看SSH服务实际生效的认证配置。
3. 可以临时在/etc/pam.d/sshd的pam_tally2配置行末尾加上debug参数，然后通过tail -f /var/log/secure实时观察系统安全日志，看是否有pam_tally2相关的调试信息输出。
4. 如果系统启用了SELinux，还需要考虑它对tallylog文件的写入限制。可以运行ausearch -m a vc -ts recent | grep tally命令检查是否有相关的拒绝记录。如果有，在RHEL/CentOS系统上，通常需要执行setsebool -P pam_tally2_read_log on来放行。

解锁被锁账户时，为什么 pam_tally2 --reset 没反应？

当账户被锁定后，执行pam_tally2 --user xxx --reset命令却没有反应，计数器纹丝不动。这大概率是/var/log/tallylog文件本身出了问题。

这个文件默认的所有者和权限是root:root和600。如果不小心被chmod改成了644，或者chown给了其他用户，pam_tally2命令在操作时可能会静默失败——不报错，但计数器就是清不掉。

安全检查和操作建议如下：

• 先用ls -l /var/log/tallylog确认文件的权限和属主是否正确。
• 如果这个文件不存在，不用担心，pam_tally2模块会在第一次记录失败尝试时自动创建它，不需要手动touch。
• 如果怀疑文件已经损坏，可以先备份然后删除它：mv /var/log/tallylog /var/log/tallylog.bak。之后再次执行pam_tally2 --user xxx --reset命令，系统会重建一个新的计数器文件。
• 务必注意：重置计数器的操作必须由root用户来执行。普通用户即使通过sudo提权，也可能因为PAM策略的限制而失败。

最后，还有一个真正容易被忽略的“时代变迁”问题：pam_tally2模块在一些较新的发行版中已经被标记为废弃。例如Debian 12、Ubuntu 22.04及之后的版本，其底层已经改用pam_faillock来替代，两者的命令和配置语法完全不同。因此，在动手配置之前，先花一分钟确认一下自己系统的版本和实际存在的PAM模块，远比盲目套用老旧教程要高效得多。