凌晨3点，值班邮箱收到数百条SSH登录失败告警：同一批公网地址轮换尝试root、admin和测试账号。安全组将22端口向全网开放，Fail2ban又未启用；临时收紧规则后，远程发布也被挡在门外。SSH暴力破解防护的难点并非封死入口，而是在运维便利、误封风险和应急恢复之间建立可验证的边界。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：zenlayer（AI云基础设施），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
{PROMO}
端口收敛不是简单关闭SSH。有维护需求时，可通过安全组最小放行，将22端口限制到堡垒机、VPN出口或固定管理网段，并让云安全组与主机防火墙规则一致。使用ServLlama盘点多台主机时，可先汇总SSH监听端口、管理来源和责任人，形成允许清单，避免只在单机修补。
判断收敛是否有效，可交叉核对三点：外部扫描只看到预期入口；安全组拒绝日志能发现绕行来源；主机侧没有重复放行。常见踩坑是办公室出口IP变化、IPv6规则未同步，最终又放回0.0.0.0/0。应保留一条经验证的应急通道，写明启用条件、操作人和失效时间，避免把运维人员锁在门外。
入口收窄后，SSH密钥认证应成为首选。切换前应保留受控密码窗口，为每台机器、每个运维人员配置独立密钥，私钥设置口令或硬件保护，并离线备份公钥与指纹；确认密钥与回退方案后再关闭密码交互，落实Root登录禁用。这样即使口令库泄露，攻击者也难以仅靠猜密码取得会话。
Fail2ban自动封禁不是失败一次就拉黑。应按失败次数、时间窗口和来源行为设阈值，对常用管理地址设置白名单，并观察误封率。解析器要覆盖实际日志格式、时区和IPv6，封禁动作最好原子写入。拉黑只能止血：日志应同步到独立节点，保留源IP、目标账号、失败原因和时间戳；大量失败后出现成功登录时，立即触发高优先级登录审计告警。
判断策略是否健康，可每周抽样回答：暴露入口是否符合清单；失败尝试是否具有攻击特征；误封是否影响发布；失败风暴后是否出现异常成功。若只看封禁数量上升，而没有日志留存、攻击收敛和成功事件告警，就仍是自动动作，不是闭环防护。
Fail2ban 解析 SSH 失败日志，将同一来源在 findtime 内的失败累计到 maxretry，超阈值后按 bantime 临时封禁。它只是阻断层，不能替代 SSH密钥认证；阈值过低也会误封 NAT 或共享出口中的正常用户。
常见坑有：jail 未启用或日志路径、正则不匹配；iptables、nftables、ufw、Docker 与云防火墙规则互相覆盖，造成刚封即解；日志轮转、时区变化使解析失效；封禁过久且无人复核。上线前应核对过滤器、action、期限，并用测试账号验证命中、解封和重启恢复。
还要确认日志中的来源地址。若 SSH 看到代理或负载均衡节点，按该地址封禁会误伤管理链路。封禁应限定 SSH 端口，并为 Fail2ban自动封禁、解封和规则加载失败产生监控事件。
先运行 sshd -t 检查语法，再用 sshd -T 确认 PubkeyAuthentication 为 yes、PasswordAuthentication 为 no、PermitRootLogin 为 no；核对授权密钥归属、用途、期限与指纹，删除闲置密钥。保持当前会话不关闭，另开终端验证密钥登录和 sudo 权限，通过后再 reload。
检查 安全组最小放行：仅开放必要端口，来源限定为办公出口 IP 或零信任网关，禁止 0.0.0.0/0 与 ::/0 暴露 SSH。运行 fail2ban-client status sshd，核对 jail、封禁数、期限及实际规则，并确认告警通道收到测试事件。
最后落实 Root登录禁用 与 登录审计告警：集中采集 auth.log、journald、wtmp、btmp，关联失败后突然成功、异常时段、异常来源和新增密钥指纹，将事件送入 SIEM。告警按 IP、账号和短时失败次数聚合以减少噪声，但保留封禁与解封记录。
全部通过后再收紧来源，并定期复核账号、密钥、规则和阈值；变更务必保留回滚路径，避免配置失误造成远程失联。
