服务器 SSH 一直被人暴力破解？先看懂登录日志，再谈防护

公网上的 Linux 服务器只要开着 22 端口，几乎没有哪台能躲过 SSH 暴力破解。把一台刚装好的主机放到公网，用不了几个小时，/var/log/auth.log 里就会出现成片的 Failed password——来源 IP 来自各个国家，用户名从 root、admin 到 ubuntu、test 一应俱全。这类攻击绝大多数不是针对你个人，而是互联网上持续运行的自动化扫描器，但它会带来两个现实后果：一是持续消耗带宽和 CPU；二是只要有一个账户用了弱密码，被撞开只是时间问题。

这篇文章讲三件事：SSH 暴力破解到底是怎么发生的、如何从登录日志里确认自己正在被扫、以及常见的防护误区。最后再谈怎么把“登录”这件事收敛到统一入口，用强认证和审计来兜底。

攻击者在干什么：从端口扫描到撞库

一次典型的暴力破解不是“某个人在对着你的机器试密码”，而是一套全自动流程。

第一步是发现目标。攻击者用扫描器对整段公网 IP 发起 TCP 连接探测，22、3389、5432 这些端口一测便知。这一步不需要任何交互，几秒钟就能扫完一个 C 段。

第二步是识别服务。连上 22 端口后，SSH 服务端会主动返回自己的版本字符串，形如 SSH-2.0-OpenSSH_8.9p1。攻击者据此判断你用的是哪个发行版、什么版本，然后挑选对应的字典。

第三步是用户名枚举。真正的攻击会先试探一批常见用户名：root、admin、git、oracle、ubuntu、test、postgres……对于某些配置不当的 OpenSSH 版本，服务端对不同用户名的响应差异，还能帮助攻击者确认某个用户名是否存在。

第四步是字典爆破。拿到用户名后，攻击者用弱口令字典逐个尝试。字典里排在最前面的永远是 123456、password、root、admin123、qwerty 这类内容。如果目标账户恰好用了弱密码，撞开的概率并不低。

与纯字典爆破相近的还有一种叫撞库的变体：攻击者不猜密码，而是拿已泄露数据库里的账号密码组合去试。如果你在多处用了同一个密码，别处泄露一次，这里就会被撞开。这也是为什么密码一旦泄露，只改掉单台服务器的密码还不够。

理解这套流程，就能明白为什么“改端口”作用有限：扫描器不是靠记忆，而是靠全端口探测，改到 2222 照样会被扫到。

从日志里认出暴力破解

判断自己是不是正在被扫，最直接的办法是看登录失败日志。Debian/Ubuntu 系看 /var/log/auth.log，RHEL/CentOS 系看 /var/log/secure，用 systemd 的发行版也可以直接查 journal：

journalctl -u sshd --since "1 hour ago" | grep "Failed password" | tail -20

暴力破解的日志有几个明显特征：

• 同一来源 IP 高频出现。一个 IP 在短时间内发起几十上百次失败登录，这不是正常用户输错密码，而是脚本。
• 用户名呈枚举特征。连续出现 root、admin、test、oracle 等互不相关的用户名。
• 失败间隔极短。正常用户输错密码后会有思考时间，攻击脚本则是毫秒级连发。
• 来源 IP 陌生且分散。如果来源是数据中心 IP 段（而非你的办公网或家庭宽带），基本可以断定是扫描。

怎么区分正常输错密码和暴力破解？正常场景下，用户输错一两次后要么改用密钥登录成功，要么过一会儿再重试；而暴力破解是同源 IP 的密集失败，且几乎没有一次成功。看一段日志里“失败次数 / 成功次数”的比例，比只看失败次数更能说明问题。

被封禁的尝试可以用 lastb 查看：

lastb | head -20

把这两个命令的结果放在一起看，就足够判断攻击的规模、来源和持续时间。

三个常见误区

第一个误区是改端口能防爆破。前面说过，扫描器做的是全端口探测，2222 和 22 一样会被扫到。改端口顶多让那些只扫默认端口的低端脚本略过你，对有耐心的攻击者毫无意义，还徒增运维成本。

第二个误区是以为 fail2ban 是全部。fail2ban 读日志、封来源 IP，确实能挡掉大部分噪声，但它封的是“来源 IP”而非“凭据”。攻击者用僵尸网络换个 IP 再来，fail2ban 就得不断更新封禁名单；而真正的威胁——弱密码和共享密码——依然躺在那里没被解决。防护的重点应该是“让密码失效”，而不是“封住某个 IP”。

第三个误区是只禁用 root 登录就安心了。禁用 root 直接登录是应该做的，但攻击者照样会枚举其它用户名。PermitRootLogin no 只是把攻击面从 root 挪到了 admin、ubuntu 这些同样常见的账号上。

把登录收敛到统一入口

在谈统一入口之前，先确认单机层面的基线做对了：关闭密码登录改用密钥、给所有可登录账户禁用弱密码、必要时用防火墙限制允许登录的来源 IP。这些是最省事也最有效的第一步——不做这些，再强的统一入口也只是把问题留在了后面。

逐个服务器去配 fail2ban、改配置、看日志，几十台主机还能应付，几百台就顾不过来了。更彻底的做法是把“登录”这件事从每台机器上收回来，集中到一个入口做管控。

入口层做三件事，风险就能大幅下降：

措施	解决什么问题
强认证（OTP / Passkey）	即使密码泄露，没有第二因素也无法登录
集中登录日志	谁在何时从何地登录过，一目了然
统一授权	登录后只能碰被授权的资产

其中强认证是最关键的一环。密码本身不可靠——它能被猜测、被泄露、被撞库。给登录叠加一个基于时间的一次性密码（TOTP），或者干脆换成 Passkey/WebAuthn，攻击者即使拿到了密码也进不来。这一步直接掐断了暴力破解的命脉：破解的目标是“猜中密码”，而双因素认证让“猜中密码”不再等于“能登录”。

TOTP 和 Passkey 的差别在于：TOTP 仍有一个共享密钥，只是每 30 秒变一次；Passkey 用公私钥对完成认证，私钥不出设备，从根本上没有“密码”可偷。

登录日志本身也是证据。等保、ISO 27001 等框架都要求登录行为可追溯——谁、何时、从何地登录过。把登录日志集中起来，排查和审计都能落在同一个地方，具体可对照合规与审计的映射关系。

在 Next Terminal 这类开源堡垒机中，SSH 资产统一经由堡垒机接入，登录时可叠加 OTP 双因素认证 与 通行密钥，登录行为记录在资产访问日志里。配合 SSH 网关，ssh user@host 的使用习惯也能保留，入口收敛后暴力破解就变成了“对着统一入口反复碰壁”。