CentOS 7 的账户锁定策略通常由 pam_faillock.so 控制，系统默认也更推荐使用该模块；而 pam_tally2.so 已逐步弃用，二者不能同时配置，否则很容易造成账户锁定规则冲突、失效或不生效。
账户锁定策略由 pam_tally2.so 还是 pam_faillock.so 控制？
在 CentOS 7 中，默认更推荐使用 pam_faillock.so 来管理登录失败后的账户锁定策略，但许多旧教程、历史脚本或运维文档仍然沿用 pam_tally2.so。需要特别注意的是，这两个模块不能混合使用，否则可能导致账户锁定配置冲突，甚至完全失效。
相较之下，pam_faillock.so 属于更新、更稳定也更适合当前环境的方案：它可以独立保存登录失败计数，默认存放位置在 /var/run/faillock/，并且无论是 SSH 远程登录还是本地终端登录，通常都可以按照统一规则生效。pam_tally2.so 则依赖 /var/log/tallylog；更麻烦的是，在某些 PAM 配置顺序下，它对 SSH 登录可能根本不起作用，除非你额外显式修改 /etc/pam.d/sshd。
如果你使用的是新安装的 CentOS 7（≥7.4），并且 PAM 配置基本未改动，建议优先使用 pam_faillock.so；如果当前系统已经存在 pam_tally2.so 规则且运行稳定，则不建议为了切换而强行修改，以免引发新的认证问题。
修改 /etc/pam.d/system-auth 实现全局锁定
要让账户锁定策略全局生效，必须同时在 auth 和 account 段中写入对应规则，而且配置顺序非常关键：失败计数需要在认证前触发，解锁与状态检查则要在认证后完成校验。
- 在
/etc/pam.d/system-auth文件顶部（必须靠近第一行）插入以下三行：
auth [default=ignore] pam_faillock.so preauth silent deny=5 unlock_time=180 fail_interval=900 auth [default=die] pam_faillock.so authfail deny=5 unlock_time=180 fail_interval=900 account required pam_faillock.so
参数说明：
deny=5：连续输入错误 5 次密码后立即锁定账户unlock_time=180：普通用户在 180 秒后自动解锁fail_interval=900：仅统计最近 15 分钟内的登录失败次数，避免长时间累计造成误判authfail这一行必须紧跟在preauth行后面，中间不能插入其他auth规则- 如果希望 root 账户也被锁定，可在两行末尾追加
even_deny_root参数
SSH 登录也想生效？必须改 /etc/pam.d/sshd
很多人在 CentOS 7 修改账户锁定策略后发现 SSH 登录没有生效，原因就在于：/etc/pam.d/system-auth 的改动默认并不会直接作用于 SSH——因为 SSH 使用的是自己的 PAM 调用链，它不会在 auth 段直接 include system-auth（通常只 include account 和 password 段）。
因此，若你希望 SSH 登录失败次数也能触发锁定，就必须单独配置 /etc/pam.d/sshd：
- 在
/etc/pam.d/sshd文件最前面插入与上方完全一致的三行（auth两行 +account一行） - 不要复制到文件中间或结尾，否则相关规则可能被跳过，导致 SSH 账户锁定策略不生效
- 修改完成后执行
systemctl restart sshd使配置生效 - 验证方法：用另一台机器连续多次输入错误密码，第 5 次之后即使密码正确也无法登录，同时
faillock --user xxx应显示Failures: 5
常见失效原因和排查命令
如果 CentOS 7 账户锁定策略已经写入，但实际测试仍然没有效果，通常大概率是以下几个常见问题：
- PAM 配置行位置错误：例如插在
auth [success=1 default=ignore] pam_unix.so后面，就可能导致 preauth 被直接跳过 - 参数拼写有误：比如把
unlock_time写成unlock-time，或者漏掉等号，PAM 往往会直接忽略整行配置 - 服务未重启：修改
sshd配置后如果忘记执行systemctl restart sshd，新策略不会生效 - 测试用户之前已被锁定但没有清空：可先使用
faillock --user username --reset重置失败计数后再重新测试 - SELinux 阻止写入 /var/run/faillock/：可临时切换到 permissive 模式进行验证，确认问题后再进一步调整安全策略
最终真正决定策略是否生效的依据，是 faillock 命令输出结果以及 /var/run/faillock/ 目录下是否生成对应文件，而不是日志中是否出现“pam_faillock”字样。
