Linux账户锁定策略需协同配置deny、fail_interval和unlock_time三参数，兼顾安全与可用性：终端账号建议deny=6/fail_interval=900，公网SSH收紧为deny=3/fail_interval=300，root需启用even_deny_root或禁用密码登录；unlock_time按场景设为1800秒（业务）、600秒（测试）或0（人工解锁）；须确保PAM中account required行存在、避免多文件重复加载、保障/run/faillock/目录持久性，并通过faillock命令验证及预设救援通道。
Linux账户锁定策略不是“设个天数就完事”，关键在于平衡安全性和可用性：次数太低容易误锁，太高起不到防护作用；时间太短防不住暴力尝试，太长又影响运维。实际配置中，deny（失败次数）、fail_interval（统计窗口）和unlock_time（自动解锁时长）三者必须协同设置，不能孤立调优。
合理设定失败次数与统计时间窗口
默认5次失败即锁定看似稳妥，但对普通办公或开发环境可能过于敏感。建议按场景调整：
- 终端直连或内网管理账号：可设为
deny=6、fail_interval=900（15分钟内累计6次）——兼顾输入失误容忍度与攻击成本 - 暴露在公网的SSH服务：建议收紧为
deny=3、fail_interval=300（5分钟内3次），配合防火墙联动（如fail2ban）提升纵深防御 - root账户需额外加
even_deny_root参数，避免被绕过；但生产环境更推荐禁用root密码登录，改用密钥+sudo管控
解锁时长要匹配响应能力
unlock_time不是越长越好。24小时（86400秒）适合无人值守服务器，但日常运维中常导致“锁了自己进不去”。实用建议：
- 常规业务服务器：设为
unlock_time=1800（30分钟）——足够阻断短时爆破，又不至于等太久 - 测试/开发机：用
unlock_time=600（10分钟）快速验证策略，降低调试成本 - 若希望永久锁定直到人工干预，设
unlock_time=0，但务必确保有备用root访问通道（如console、带外管理）
避免策略冲突与配置失效
常见失效原因不是参数写错，而是逻辑链断裂。务必检查以下三点：
-
account required行缺失：仅加auth规则不够，必须有
account required pam_faillock.so启用状态校验，否则系统根本不会读取锁定标记 -
多PAM文件重复加载：比如Ubuntu同时在
common-auth和sshd里配了pam_faillock，会导致计数翻倍。建议只在通用认证文件（如common-auth或system-auth）中配置一次 -
faillock状态路径权限异常：默认记录在
/run/faillock/，若该目录被清空（如重启或tmpfs刷新），历史失败计数丢失。生产环境可考虑用--use-authtok配合持久化存储，或定期备份关键用户状态
验证与应急响应要点
上线前不测试 = 埋雷。每次修改后必须执行：
- 用非root账号在新终端反复输错密码，观察第
deny次是否拒绝，再等fail_interval秒后重试，确认是否仍被拒 - 运行
faillock --user <用户名>，核对输出中的Failures total、Lockout time和Last failure是否符合预期 - 用root执行
faillock --user <用户名> --reset，确认能立即清除状态并重新登录 - 提前记好救援方式：若意外锁死，可通过单用户模式、Live CD 或带外终端用root重置
