Ubuntu配置Fail2ban保护SSH：日志来源、封禁与解封验证
Fail2ban 会分析日志中符合过滤规则的事件，并调用动作限制对应来源。它适合减少持续重复的认证尝试，但不能替代系统更新、SSH 密钥登录或合理的管理入口限制。配置前应已具备可用的 SSH 会话和平台控制台等备用入口，避免测试时把自己锁在外面。
先确认系统如何保存SSH认证日志
本文面向使用 systemd 的 Ubuntu 24.04，软件包具体版本与发行版默认动作可能不同。先检查认证失败是否出现在 journal 中，再决定后端。若系统主要写独立日志文件，应按实际文件配置，不能同时套用两种读取方式。
sudo journalctl -u ssh --since "30 minutes ago" --no-pager
sudo systemctl status ssh --no-pager
如果服务单元名称不同，用实际名称查询。日志没有事件时，先确认时间范围、服务状态和日志权限，不要直接断定没有异常。Fail2ban 配置说明描述了各类后端；本文仅使用已确认能够读到 SSH 事件的 systemd 场景。
安装后只建立必要的本地覆盖
通过系统软件仓库安装并查看服务状态。不要从陌生网站下载并直接运行所谓增强防护脚本。已有 Fail2ban 环境先备份现有配置，避免把其他 jail 的规则覆盖掉。
sudo apt update
sudo apt install fail2ban
sudo systemctl status fail2ban --no-pager
在 /etc/fail2ban/jail.d/sshd.local 建立以下示例。示例假设 SSH 监听 22 端口；实际使用其他端口时填写真实端口，确保封禁动作与服务入口一致。
[sshd]
enabled = true
backend = systemd
port = 22
maxretry = 5
findtime = 10m
bantime = 10m
这表示在指定观察窗口内达到失败次数阈值后，执行一段时间的封禁。它是便于理解的起始示例，不是所有业务通用的最佳参数。systemd 后端不应再配置文件式 logpath；项目的 jail.conf 示例说明了这个差异。
配置检查和状态检查各看什么
先测试配置，再重新加载服务。下面命令只在已经确认配置无误后逐步执行，前一步失败就先处理错误，不继续向后操作。
sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
总状态里出现 sshd 说明 jail 已启动；还要检查服务日志，确认过滤器能够读取事件、封禁动作没有执行错误。看见“运行中”不能证明实际网络路径已经受控，尤其在容器、复杂防火墙或不同网络命名空间环境中，更应检查规则作用的位置。
怎样测试而不影响正常管理员
使用有授权的测试环境和独立来源进行少量受控认证失败，记录来源地址、时间及计数变化。保留原来的正常管理会话，先确定备用入口能够使用。不要从唯一管理地址反复尝试密码，也不要为了验证规则对其他人的服务器产生认证请求。
共享出口下多个正常用户可能被同一来源地址代表，因此阈值和封禁时间需要结合实际使用习惯调整。固定受控管理地址可评估是否加入可信列表，但不要把大网段随意整体放行。测试结束后清理临时授权，并核对正常登录仍然成功。
误封时先恢复入口，再复核原因
从保留的会话或备用控制台确认被封的真实地址，使用 sudo fail2ban-client set sshd unbanip 203.0.113.10 解封；这里的文档示例地址必须替换为已核实的目标。随后检查错误密码、过期密钥、监控探测或共享出口等原因，避免刚解封又立即触发。
如果配置导致服务无法启动，恢复本次修改前的本地配置并重新测试。完成后把后端、端口、阈值、备用入口和最近一次验证结果记录下来。Fail2ban 的价值在于一条可以观察、验证和维护的规则，而不是安装后就无人检查的“安全开关”。