fail2ban是最直接有效的防御手段，它监控auth.log或secure日志，识别连续失败的SSH登录并调用iptables/nftables封禁IP；需启用sshd过滤器、设maxretry为3～5、bantime≥3600秒，适配nftables后启动服务并验证状态。
用 fail2ban 自动封禁反复失败的 IP
fail2ban 是最直接有效的防御手段，它监控 /var/log/auth.log（或 /var/log/secure，取决于发行版），识别连续失败的 SSH 登录尝试，并自动调用 iptables 或 nftables 封禁源 IP。
安装后默认已包含 sshd 过滤器，但需确认启用：
- 检查
/etc/fail2ban/jail.local中[sshd]段是否设置enabled = true -
maxretry建议设为 3～5，bantime至少 3600（1 小时），避免误封后立即解封 - 若系统用
nftables，需在[sshd]下指定backend = systemd或确保banaction匹配（如banaction = nftables） - 启动服务：
systemctl enable --now fail2ban，之后用fail2ban-client status sshd验证运行状态
禁用密码登录，强制使用密钥认证
只要关闭密码登录，暴力破解就失去意义——攻击者无法靠穷举口令进入系统。
操作前务必确保已有可用的 SSH 密钥对且公钥已写入 ~/.ssh/authorized_keys，否则会锁死自己：
- 编辑
/etc/ssh/sshd_config，将PasswordAuthentication设为no - 同时确认
PubkeyAuthentication yes和AuthorizedKeysFile .ssh/authorized_keys未被注释或改写 - 重启服务：
systemctl restart sshd；建议开第二个终端测试新连接再关闭原会话 - 注意：某些云平台控制台（如 AWS EC2 Serial Console）可能依赖密码或特殊凭证，禁用前需确认备用访问通道
修改默认 SSH 端口并限制监听范围
把 SSH 从 22 换到非标端口（如 2222）不能替代其他防护，但能过滤掉大量自动化扫描流量；配合 ListenAddress 可进一步缩小暴露面。
这不是“隐藏即安全”，而是降低日志噪音和初始攻击密度：
- 在
/etc/ssh/sshd_config中取消注释并修改Port行，例如Port 2222 - 添加
ListenAddress指定仅监听内网或特定 IP：ListenAddress 192.168.1.100或ListenAddress ::1（仅本地 IPv6） - 防火墙必须同步放行新端口：
ufw allow 2222或nft add rule ip filter input tcp dport 2222 accept - SELinux 用户还需运行
semanage port -a -t ssh_port_t -p tcp 2222，否则sshd启动失败
用 sshd 的 AllowUsers / AllowGroups 严格限定可登录账户
即使密钥或密码泄露，攻击者也必须猜中用户名才能发起认证请求。限制允许登录的用户列表，等于给入口加了一道白名单门禁。
这比单纯禁用 root 登录更进一步，尤其适合多用户环境：
- 在
/etc/ssh/sshd_config中添加AllowUsers alice bob@192.168.1.*（支持用户名+IP 模式） - 或使用
AllowGroups sshusers，然后把合法用户加入该组：usermod -aG sshusers alice - 注意：配置后所有未显式列出的用户（包括
root）均无法登录，哪怕密钥正确也不行 - 若用
AllowGroups，确保组名拼写与/etc/group一致，大小写敏感
真正起效的防护是组合动作：fail2ban 应对试探、密钥登录消除口令爆破面、端口与地址限制减少无效连接、白名单收窄合法身份范围。最容易被忽略的是变更配置后的连通性验证——别等锁住自己才想起没留后门。
