1G 内存云服务器加固实录：三个差点让我失联的坑

背景

一台 2核1G 的入门款云服务器，Debian 12，上面跑着一个常驻服务，监听 443 端口对外提供服务。内存只有 1G，属于"够用但要省着用"的水平。安全加固本来是例行操作，结果三个坑连环踩，每一个都足以让人当场失联。记录下来，给同样在低配小机上做加固的朋友避雷。

坑一：fail2ban 把自己封了

我的登录链路经过一层转发，服务器看到的来源 IP 并不是常用办公网的 IP。而 SSH 握手偶发抖动会产生重试，配上我一开始设置的 aggressive 模式 + maxretry=4，直接被判成爆破，nftables reject。

表现就是：Connection refused，但服务器明明活着，控制台 VNC 登录一切正常。

两个教训：

• fail2ban 用 normal 模式，maxretry 放宽到 6 以上，bantime 适当缩短；
• 无 rsyslog 的系统记得 backend = systemd，否则规则读不到日志，根本不生效。

救急通道：提前留一个能登录的跳板机，用 fail2ban-client set sshd unbanip 解封。

坑二：SSH 握手被中间设备掐断

Debian 12 的 sshd 默认提供 sntrup761x25519-sha512 后量子密钥交换算法，在部分运营商链路上会被中间设备直接打断，客户端卡在 SSH2_MSG_KEXINIT sent 然后超时，现象和端口被封一模一样，非常误导。

解决：sshd_config 和客户端都固定 KexAlgorithms curve25519-sha256。老算法反而最稳。

坑三：一键脚本 kill 掉 443

图省事跑了某知名工具箱的"一条龙调优"，它内部的 check_port 会把占用 80/443 的进程直接 kill——我那个监听 443 的服务就这么没了。它的改 SSH 端口功能还会把 sshd 挪到高位端口，而云控制台安全组没放行新端口，等于自己断网。

结论：云上小机别跑一键全家桶，要哪项功能单独执行，改之前想清楚副作用。

加固清单（复盘版）

• sshd 自定义 conf 用 00- 前缀（sshd 配置首个值生效，顺序很重要）
• fail2ban：normal 模式 + systemd backend
• 开 BBR：/etc/sysctl.d/99-bbr.conf，net.ipv4.tcp_congestion_control=bbr
• 任何远程变更前，保持第二个 SSH 会话在线

1G 内存的小机不奢侈，但省着用完全够——前提是别把它折腾死。