SSH 总被暴力破解？给 ECS 做一次登录加固：密钥、端口与 Fail2ban 一次落地

刚买的云服务器上线不到一天，登录日志里就可能已经躺着几百条失败记录：来自世界各地的地址，拿着常见的用户名和弱口令一个一个试。这不是针对你，而是全网扫描的常态——只要端口开着、密码登录开着，试错成本几乎为零。对攻击者来说，撞中一台就是一台肉鸡；对你来说，被撞中一次，数据、算力和账单都可能跟着遭殃。

SSH 加固不需要很复杂的安全知识，也不需要买额外的服务。核心思路只有一条：让"猜密码"这条路走不通，再把"试错"本身变得昂贵。下面这套做法，一台服务器半小时就能配完，而且每一步都能随时回退。

一、先看清现状：你的服务器正在被试探

动手改配置之前，先看一眼登录日志，确认问题真实存在，也顺便留个加固前的基线。登录失败记录一般在系统认证日志里，翻最近的一两百行，就能看到规律：失败的用户名高度集中在 root、admin、test、ubuntu 这几个；来源地址分散在不同网段；时间上几乎不间断，凌晨也不停。

这些记录说明三件事。第一，攻击是自动化的，不是有人盯着你这台机器手动敲命令，脚本 24 小时都在跑。第二，攻击者赌的是"弱口令 + 常见用户名"，只要你的密码不在常用口令表里，单次被猜中的概率很低，但架不住它一直试。第三，光靠"密码够复杂"是不够的——密码再复杂，也扛不住永不停歇的试错，何况很多人图省事，几台服务器共用同一个密码，一台被撞中，处处跟着失守。

所以加固的目标要定清楚：不是让密码更难猜一点，而是把密码登录这条路直接关掉；同时给试错加上代价，让脚本试几次就被挡在外面。看完日志再动手，改完再看一次日志，对比才有意义。

二、密钥登录：把"猜密码"变成"猜不到"

最关键的一步，是改用密钥登录。密码是"你知道的一串字符"，知道就能登录；密钥是"一对数学上绑定的钥匙"，只有手里拿着私钥的那台电脑才能开门。攻击者不知道你的私钥长什么样，也没法靠枚举把它猜出来，这条路从原理上就走不通了。

做法分三步。第一步，在你自己的电脑上生成一对密钥。生成时可以给私钥加一个口令，相当于给钥匙再加一把锁：就算私钥文件不小心泄露，没有口令也用不了。私钥只留在自己的电脑上，不要传到服务器、不要发到群里、不要放进代码仓库。

第二步，把公钥放到服务器上指定用户的家目录里，放到专门存放授权密钥的文件中，并把权限收紧：家目录不能让别人写，密钥文件只能自己读。权限太松时，服务端会直接拒绝使用这把钥匙，这是保护机制，不是故障——按提示把权限改对就行。

第三步，先别急着关密码登录。用新开一个终端窗口，只用密钥试着登录一次，确认能正常进去，再去动服务端配置。永远不要在"唯一一个登录窗口"里改配置：改错了、退出来了，服务器就再也进不去了。确认密钥能用之后，再把服务端的密码登录关掉，只保留密钥登录，同时禁止 root 用户直接用 SSH 登录，日常操作先用普通用户登录，需要提权时再切换。

改完配置要重启 SSH 服务让新配置生效，重启前先检查配置文件的语法有没有写错，语法报错时不要重启，先改对。重启后同样用新窗口验证：密钥能登录、密码登录被拒绝、root 直接登录被拒绝，三条都通过，这一步才算做完。最后把私钥备份一份到安全的地方，比如加密的 U 盘或密码管理器，电脑丢了、重装了，还能靠备份的私钥登录。

三、换端口与收紧入口：让扫描器先找不到门

SSH 默认走 22 端口，全网的扫描器都知道这个数字，第一个试的就是它。把端口换成一个不常用的高位端口，不能从根本上挡住有针对性的攻击，但能挡掉绝大部分"只扫默认端口"的自动化脚本，登录日志立刻会清净很多。

换端口时要注意配合安全组一起改：服务器里改了端口，云平台的安全组也要放行新端口、收紧旧端口，否则会出现"配置改对了，人却进不去了"的情况。顺序上建议先在安全组里放行新端口，再改服务器配置、重启服务，用新端口验证能登录后，最后再把旧端口从安全组里关掉。改端口不是"一改就安全"，它只是减少噪音、降低被扫到的概率，真正的防线还是密钥登录和下面的封禁机制。

更进一步的做法，是收紧能连 SSH 的来源。如果你的办公网络有固定出口地址，或者你只在家里和公司两处登录，可以在安全组里只放行这两个地址段的 SSH 访问，其他来源一律拒绝。这样一来，即使攻击者知道端口、拿到了用户名，连 TCP 连接都建立不起来。固定地址会变的场景要留个后路：比如保留一台跳板机，或者准备好通过云平台控制台的网页终端登录，避免把自己锁在外面。

还有一个容易被忽略的入口：云平台自带的网页终端和救援模式。它们是"服务器连不上了"时的救命通道，平时也要确认它们的登录方式同样走了密钥或平台鉴权，不要留一个"不用密钥也能进"的后门。安全加固最怕的就是只加固了正门，后门还敞着。

四、Fail2ban：试错几次就封掉，让脚本知难而退

密钥登录关掉了密码这条路，但攻击者并不知道，他们的脚本还是会不停地试。Fail2ban 的作用，就是盯着认证日志，发现某个地址短时间内失败次数太多，就自动把它封掉一段时间，封禁时长可以越犯越长。

它的原理很直白：读日志、数失败次数、够数就加一条防火墙规则。配置时主要定三个数字：多长时间内算一次统计窗口、失败多少次触发封禁、封禁多长时间。一个常见的起点是 10 分钟内失败 5 次，封禁 1 小时；对 SSH 这种"正常人输错两三次就停手"的服务来说，这个阈值既不会误伤自己，也足以让脚本付出代价。自己输错密码被封了也不用慌，等封禁时间过去就能再试，或者换一个地址登录后把自己放出来。

装好之后要验证它真的在工作：故意用错误的密码连续试几次，确认来源地址被封掉、再也连不上；等封禁解除后，正常登录又恢复。只装不验证，等于没装。还要定期看一眼它的封禁记录：被封的地址多不多、有没有反复出现的固定网段、封禁时长够不够长。反复出现的网段可以考虑在安全组里长期拉黑，省得每次都靠 Fail2ban 临时封。

Fail2ban 只能保护它盯着的日志对应的服务，SSH 配好了，数据库、后台管理页面如果也暴露在公网，同样需要各自的防护。不要以为装了一个 Fail2ban，全站就安全了，它只是纵深防御里的一层。

五、日常习惯：加固不是一次性的事

配置改完、Fail2ban 跑起来，加固并没有结束。安全是一件需要持续做的小事，重点在几个习惯上。

第一，定期看日志。每周花五分钟翻一下登录失败记录和封禁记录：失败次数是不是突然暴涨、有没有新的攻击手法、封禁规则有没有误伤正常登录。日志暴涨往往是攻击升级的信号，也是提醒你检查其他入口的时候。

第二，密钥要轮换。员工离职、电脑丢失、怀疑私钥泄露，都要第一时间把对应的公钥从服务器上删掉，重新生成一对新的。公钥文件里躺着几个"早就不用的旧钥匙"，是很多服务器的通病，清理一次只要一分钟。

第三，系统要及时更新。SSH 服务本身、操作系统、Fail2ban 都有可能爆出漏洞，定期更新补丁是成本最低的防护。更新前先拍一张快照——重要操作之前先备份，这个习惯在前面快照那篇里讲过，这里同样适用，更新出问题可以直接回滚。

第四，别在服务器上放多余的东西。不用的用户及时删掉、不用的端口及时关掉、不用的服务及时停掉。每个多余的入口，都是多一个被试探的点。最小权限原则说起来简单，落到实处就是：只留必需的，定期清掉其余的。

六、落地清单：半小时配完的加固步骤

第一，看一眼登录日志，确认正在被试探，留个基线。第二，在自己电脑上生成密钥对，公钥放到服务器并收紧权限。第三，用新窗口验证密钥能登录，再关掉密码登录、禁止 root 直接登录，重启服务后逐项验证。第四，换一个不常用的 SSH 端口，安全组先放行新端口、验证通过后再关旧端口；有固定出口地址的，进一步只放行信任来源。第五，装好 Fail2ban，定好统计窗口、触发次数和封禁时长，故意输错几次验证封禁真的生效。第六，把私钥备份到安全的地方，定期看日志、轮换密钥、及时更新系统、清理多余用户和端口。

SSH 加固没有哪一步是高深的，难的是"每一件都做到位"。密码登录一关，暴力破解的路就断了大半；端口一换、Fail2ban 一开，剩下的试探也变得费力不讨好。半小时的配置，换来的是登录日志从每天几百条失败记录变成偶尔几条，这笔买卖，怎么算都值。