很多新上线的云服务器，最先遇到的不是业务流量，而是 SSH 扫描。只要公网 IP 暴露，22 端口很快就会出现大量 Failed password、Invalid user、Connection closed 等日志。它们未必已经攻破服务器，但会持续消耗日志、带来告警噪声，也说明机器正在被自动化脚本盯着。

这篇文章给一套适合小团队和个人站长的 SSH 加固流程：先用云安全组挡住大部分无效来源，再把登录方式改成密钥优先，最后用 Fail2ban 针对异常尝试做自动封禁。所有步骤都带验证和回滚，避免把自己锁在服务器外面。

一、先判断是不是被暴力扫描

登录服务器后，先看最近的 SSH 认证日志。Ubuntu/Debian 常见路径是 /var/log/auth.log，CentOS/RHEL 常见路径是 /var/log/secure。

sudo grep -E "Failed password|Invalid user|Accepted|Connection closed" /var/log/auth.log | tail -80
sudo journalctl -u ssh --since "2 hours ago" | tail -80

如果看到大量陌生 IP、陌生用户名、短时间高频失败登录，就说明 SSH 正在被扫。不要先急着改端口。改端口只能降低噪声，不能替代访问控制、密钥登录和日志封禁。

二、第一层：云安全组先收口

安全组是云服务器前面的第一道网络门。腾讯云官方文档说明，安全组规则可以控制实例入站和出站流量；如果没有规则，默认会拒绝流量。对 SSH 来说，最稳的做法是：

• 不要长期开放 0.0.0.0/0:22；
• • 如果办公出口 IP 固定，只允许该 IP 访问 22；
• • 如果多人协作，使用跳板机或 VPN，再让业务服务器只允许跳板机访问；
• • 临时排障需要开放时，设置明确时间窗口，完成后立即收回。

安全组调整后，先从允许的来源测试：

ssh -i ~/.ssh/prod_ed25519 ubuntu@your_server_ip

再从非允许来源测试，应该无法连上 22 端口。这个验证比“规则看起来配置了”更重要。

三、第二层：确认密钥登录可用，再关闭密码登录

修改 SSH 配置前，一定先开第二个 SSH 会话，不要关闭当前会话。然后备份配置：

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
sudo grep -R "PasswordAuthentication\|PermitRootLogin\|KbdInteractiveAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

建议在 /etc/ssh/sshd_config.d/99-hardening.conf 写入覆盖配置：

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
EOF

OpenSSH 的 sshd_config 手册中，PasswordAuthentication 用于控制是否允许密码认证；KbdInteractiveAuthentication 也可能承担类似密码交互认证角色，因此两者要一起检查。写完后先测试配置，不要直接重启：

sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

然后打开一个新终端，用密钥重新登录。如果新终端能登录，再关闭旧终端。

四、第三层：Fail2ban 自动封禁异常 IP

Fail2ban 的思路是读取认证日志，根据失败次数触发封禁。官方 jail 配置中包含 [sshd] jail，可用于 SSH 服务。Ubuntu/Debian 安装：

sudo apt update
sudo apt install fail2ban -y

创建本地 jail，避免直接改默认配置：

sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF

启动并检查：

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

如果系统日志不在 /var/log/auth.log，要按发行版调整 logpath 或使用 systemd backend。不要照抄后不验证。

五、上线验证：看三类结果

第一，看 SSH 是否仍能从可信来源登录：

ssh -i ~/.ssh/prod_ed25519 ubuntu@your_server_ip

第二，看失败登录是否下降：

sudo journalctl -u ssh --since "1 hour ago" | grep -E "Failed|Invalid|Accepted" | tail -50

第三，看 Fail2ban 是否在工作：

sudo fail2ban-client status sshd
sudo fail2ban-client get sshd banned

如果安全组已限制来源，Fail2ban 可能没有太多封禁记录，这是正常的。安全组挡在前面，日志自然会干净很多。

六、常见坑和回滚

最常见的坑有三个。

第一，没确认密钥可用就关闭密码登录，导致无法登录。解决办法是在改配置前保留一个已登录会话，配置通过 sshd -t 后再 reload。

第二，只改了端口，没有收口安全组。端口改成 2222 后仍然对全网开放，只是减少低级扫描，不是安全边界。

第三，Fail2ban 日志路径不匹配。不同系统日志位置不同，必须用 journalctl、auth.log 或 secure 实际验证。

回滚方式：

sudo rm -f /etc/ssh/sshd_config.d/99-hardening.conf
sudo sshd -t && sudo systemctl reload ssh
sudo systemctl stop fail2ban

如果需要恢复备份：

sudo cp /etc/ssh/sshd_config.bak.YYYY-MM-DD-HHMM /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload ssh

七、建议的最终状态

生产服务器的 SSH 建议做到：

• 安全组只允许可信来源访问；
• • 使用密钥登录；
• • 关闭密码登录和键盘交互认证；
• • root 不允许密码直登；
• • Fail2ban 负责兜底封禁；
• • 监控 SSH 失败登录峰值；
• • 保留回滚方案和应急登录路径。
    SSH 安全不是一次性动作，而是上线基线。先把入口收紧，后面的业务部署、数据库、对象存储和备份才有安全基础。

参考资料：OpenSSH sshd_config(5) 手册、Fail2ban 官方 jail 配置、腾讯云 Security Group Overview 与安全组规则文档。