核心要点（TL;DR）

• SSH 暴露在公网必然被扫，改端口只能降噪，不能替代密钥登录与封禁。
• 禁用密码登录、只允许密钥认证是最有效的一步，改完先验证再断开当前会话。
• Fail2ban 读取 auth.log 自动封禁高频失败 IP，配合云安全组效果更好。
• 加固顺序建议：备份配置→改端口→禁密码→配 Fail2ban→限制来源 IP→复查日志。

把云服务器开好、SSH 端口暴露在公网的那一刻，暴力破解就已经开始了。很多运维和站长第一次打开 /var/log/auth.log 才发现，一天几千次失败登录是常态。本文不讲空泛的安全理念，直接按「看日志—改配置—上封禁—做复查」的顺序，给出一套可以照着敲命令的 SSH 防爆破实战方案。

一、先确认：你的 SSH 正在被爆破吗

不同发行版日志位置不同，先定位再统计：

# Debian/Ubuntu
sudo grep "Failed password" /var/log/auth.log | wc -l

# CentOS/RHEL
sudo grep "Failed password" /var/log/secure | wc -l

# 查看攻击来源 TOP10
sudo grep "Failed password" /var/log/auth.log \
  | awk '{print }' | sort | uniq -c | sort -rn | head -10

如果失败次数在几百到几万量级、来源 IP 分散且集中在 root、admin 等常见用户名，基本可以判定为自动化爆破。此时不要急着封 IP，先完成下面的配置加固，封禁才有意义。

二、改端口只能降噪，不能当防线

把 22 改成高位端口能过滤掉大部分无差别扫描，但针对性扫描仍能找到。正确做法是把它当作「减少日志噪音」的辅助手段，与密钥认证、封禁策略一起用。

1. 编辑 /etc/ssh/sshd_config，加入 Port 22222（自选，避开常用端口）。
2. 云厂商安全组同步放行新端口，先放行再改配置，否则重载后连不上。
3. 执行 sudo sshd -t 校验语法，再 sudo systemctl reload sshd。
4. 保持当前会话不断开，另开窗口用 ssh -p 22222 user@ip 验证成功后再关闭旧会话。

三、禁用密码登录，改用密钥认证

这是防爆破收益最大的一步：密码登录一关，绝大多数爆破尝试直接失效。

# 本地生成密钥（已有可跳过）
ssh-keygen -t ed25519 -C "ops@example"
ssh-copy-id -p 22222 user@your-server

# 服务端配置
sudo vim /etc/ssh/sshd_config

确认以下项（注意 Ubuntu 云镜像常在 /etc/ssh/sshd_config.d/ 下有覆盖文件，需一并检查）：

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes

改完执行 sudo sshd -t && sudo systemctl reload sshd，务必另开窗口验证密钥登录成功，再断开当前连接。若被锁，使用云控制台 VNC 登录回滚配置。

四、用 Fail2ban 自动封禁高频失败 IP

密钥登录挡住大部分攻击，但日志仍会被刷。Fail2ban 读取日志、按阈值自动封禁，是 SSH 防爆破的标配。

sudo apt install fail2ban -y   # Debian/Ubuntu
sudo yum install epel-release fail2ban -y  # CentOS

sudo vim /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 22222
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

启动并验证：

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

输出中能看到当前封禁 IP 列表才算生效。CentOS 需确认 logpath 指向 /var/log/secure，否则 jail 不会触发。

五、收紧来源：安全组与登录审计

如果办公出口 IP 固定，直接在云安全组把 SSH 端口来源限制为该 IP 段，攻击面会大幅缩小。没有固定 IP 时，可只对运维人员开放，其余来源拒绝。

同时建立登录审计习惯：

• 用 lastb | head -20 查看失败登录来源。
• 用 last | head 核对成功登录是否都是自己。
• 定期检查 ~/.ssh/authorized_keys 是否被写入陌生公钥。

在防护建议层面，AegisX 的主机入侵防护能力可以对 SSH 异常登录行为做持续监测与告警，与本文的手工加固形成互补，适合不想长期盯日志的团队。

六、加固检查清单与行动建议

• 备份 sshd_config 后再改，改完必须 sshd -t 校验。
• 新端口先在安全组放行，再重载 sshd。
• 密钥登录验证成功后再禁用密码。
• Fail2ban 的 port 与改后的端口一致，jail 状态可查。
• 每周看一次 lastb 与 authorized_keys。

行动建议：今天就按「改端口→禁密码→配 Fail2ban→限来源」的顺序做完前三项，全程约半小时；完成后保留一次 VNC 兜底验证。SSH 防爆破不是一次性任务，而是配置到位后持续复查的日常习惯。

常见问题（FAQ）

SSH 被暴力破解会有什么实际后果？

绝大多数爆破不会成功，但持续尝试会消耗连接资源、撑大日志，并带来真实风险：一旦某个账号使用弱密码被撞开，攻击者常立刻植入挖矿程序、修改 authorized_keys 并横向渗透。因此不能只当噪音处理，应尽快禁用密码登录并封禁高频来源 IP。

只把 SSH 端口从 22 改成其他端口够不够？

不够。改端口只能减少自动化扫描的命中率，属于降低噪音而非安全加固。针对性扫描仍能找到新端口，真正的防线是密钥认证、禁用密码登录、Fail2ban 封禁与安全组限制来源 IP。建议改端口与这些措施一起做，而不是只改端口。

配置 Fail2ban 后为什么还是能看到大量失败记录？

Fail2ban 只处理达到阈值后的封禁，阈值之前的尝试仍会写入日志；另外若 jail 未启用 sshd、日志路径与实际不符（如 Ubuntu 用 auth.log、CentOS 用 secure），或防火墙后端未生效，封禁就不会落地。可用 fail2ban-client status sshd 查看当前封禁列表确认是否工作。

禁用密码登录后把自己锁在服务器外怎么办？

务必先在本地用密钥成功登录一次，再修改配置；修改后执行 sshd -t 校验语法并用 systemctl reload sshd 重载，保持当前会话不断开，另开窗口验证新连接。云厂商控制台的 VNC 登录是最后的兜底手段，操作前确认可用。

个人小站也需要做这些 SSH 加固吗？

需要。爆破是自动化全网扫描，与站点规模无关，小站被攻破后同样会被用作挖矿或跳板。最低成本做法是：禁用密码登录改用密钥、开启 Fail2ban 默认 sshd 规则、安全组只放行必要来源 IP，三项配置半小时内可完成。