有一个这里的行为类似但我相信这是一个不同的根本原因，或者至少需要不同的解决方案，因为这个失败不是由于 SSH 密钥造成的。
我们公司正在进行 Linux 审计，我需要启用 PAM 帐户锁定功能，以应对 3 次错误密码尝试。我之前没有 PAM 经验。
如果我pam_tally2 -u testuser在运行之后但在输入密码之前立即运行su testuser，则失败的 pam_tally 已经是 1，即使我尚未输入密码。
我理解，在我上面链接的案例中，密码前增加是由失败的 SSH 密钥交换引起的，但读完之后，man su似乎没有涉及密钥交换。所以我的问题是“为什么 su 会导致 pam_tally 在输入密码之前增加？”
我尽力确保所有登录尝试/阻止与 sshd_config、PAM、fail2ban 和 /etc/login.def 匹配，但是当 pam_tally 计算出我未曾预料到的事件时，情况就变得很棘手！
操作系统是 Ubuntu 服务器 14.04
仅对服务器进行的 PAM 配置更改是在/etc/pam.d/common-auth顶部添加此行：
auth required pam_tally2.so deny=3 unlock_time=900
谢谢！
答案1
仔细阅读pam_tally2将充分解释您所看到的行为。您期望看到多少失败的尝试在登录时发生；然而，man页面解释（重点是我的）：
本模块维护尝试访问的计数
所以它的行为完全符合预期。当你 时su user，无论你是否输入了密码（正确或错误），你都会立即尝试访问。当您随后输入正确的密码时，计数将重置为0。您已将最大尝试次数设置为3，因此一旦您输入了超出这是第四次尝试，产生了错误。
这种行为是正确的，而且现在我们了解了它的pam_tally2实际作用，所以它是合理的。