已经用密钥登录了，为什么 SSH 还在被打：三个真能堵住的配置

换了密钥登录、改了端口，仍然能在 auth.log 里看到 Failed password 不断刷，说明服务端还在接受密码认证这条路，攻击者只是在做无效尝试。改端口只能降低扫描频率，关掉密码通道才是根治。

第一步：确认密码认证真的关了

sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'

这里读的是运行时实际生效的配置，比看 sshd_config 文件可靠。如果输出 passwordauthentication yes，那前面所有的密钥配置都没挡住爆破。/etc/ssh/sshd_config.d/ 下的分片文件优先级高于主文件，改动要确认落在这个目录里的文件不会覆盖。

改完必须 sshd -t 校验语法，再 systemctl reload sshd。用 restart 会掐断当前会话，reload 不会。

第二步：只允许指定用户和指定来源

在 sshd_config 里加：

AllowUsers root@1.2.3.4 admin@10.0.0.0/8

这比 DenyUsers 白名单式更安全，其他所有用户直接被拒，连认证阶段都进不去。注意 IP 写错会把自己锁在外面，改之前先开一个已登录的会话保底。

第三步：让 fail2ban 真的命中

端口改成非标准端口后，fail2ban 的默认 sshd jail 仍按 22 端口监控日志，结果规则永远不触发。需要确认两处：

• jail.local 里 [sshd] 的 port 写成实际端口，或者留空让它从 sshd_config 自动读。
• 查 fail2ban-client status sshd 的 Total failed 与 Currently banned，两个都长期为 0 就说明日志路径或过滤器没对上。

再看后端：nftables 系统上用 iptables 动作的 jail 会静默失效，必须改成 banaction=nftables-multiport。

验证是不是真的堵住了

从另一台机器执行 ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host，正常应立刻返回 Permission denied (publickey) 而不会出现输密码的提示。看到这个结果才说明密码通道已关闭。

之后 auth.log 里仍然会有连接记录，但那只是 TCP 层的探测，不会再产生认证尝试，CPU 和日志体积都会明显下降。

本文首发于 izzsj.com，作者保留全部权利。未经书面授权，禁止任何形式采集、转载与镜像；转载请注明来源并保留原文链接。