Ubuntu/Debian SSH安全加固实战：密钥登录、UFW与Fail2ban完整配置
第 1 章：先看风险，再动配置
大家好，这期我们直接打开一台全新的 Ubuntu 22.04 服务器，现场把 SSH 从“能登录”加固到“可控、可审计”。OK，先不要急着改端口。SSH 端口改成 22022 只能减少扫描噪声，不能代替密钥、最小权限和防火墙。
先在本地生成一对 Ed25519 密钥。Windows Terminal、macOS 和 Linux 都可以执行：
ssh-keygen -t ed25519 -C "ops-2026"接下来登录服务器，创建独立运维账号，把公钥写进去。注意：保留当前 root 会话，等新账号验证成功后再关闭 root 登录。
adduser ops
usermod -aG sudo ops
install -d -m 700 -o ops -g ops /home/ops/.ssh
nano /home/ops/.ssh/authorized_keys
chown ops:ops /home/ops/.ssh/authorized_keys
chmod 600 /home/ops/.ssh/authorized_keys
ssh -p 22 ops@服务器IP屏幕上如果已经进入 ops shell，第一关通过。这个流程就是“Ubuntu SSH密钥登录教程”的核心：私钥只留在本地，服务器只保存公钥，密码泄露也不会直接暴露 SSH。
第 2 章：锁定 sshd，并设置网络边界
现在看我编辑配置文件。使用 drop-in 文件便于升级和回滚：
sudo nano /etc/ssh/sshd_config.d/99-hardening.confPort 22022
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no
AllowUsers ops先检查语法，再放行新端口。顺序不能反，否则可能把自己锁在门外。
sudo sshd -t
sudo ufw allow 22022/tcp
sudo ufw enable
sudo ufw status verbose
sudo systemctl reload ssh现在另开一个终端测试：
ssh -p 22022 ops@服务器IP
sudo sshd -T | grep -E 'port|permitrootlogin|passwordauthentication|maxauthtries'如果新连接成功，再确认旧端口没有继续监听：sudo ss -lntp | grep ssh。不要为了“安全感”盲目关闭 IPv6；如果服务器启用了 IPv6，UFW 规则和云厂商安全组也要同步检查。
第 3 章：防爆破、看日志、做最终验收
免费内置方案已经能挡住大部分误配置风险。接下来安装 Fail2ban，重点保护 sshd：
sudo apt update
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client set sshd port 22022
sudo fail2ban-client status sshd
sudo journalctl -u ssh --since "30 minutes ago"在我的测试中，连续 3 次错误认证后，Fail2ban 状态能看到被封禁地址；日志检查耗时不到 1 分钟。真实环境还要检查云安全组，只开放业务所需端口，禁止把数据库端口直接暴露到公网。完整的“Linux服务器安全检查命令”可以从端口监听、登录日志、sudo 记录三处交叉确认。
如何验证已经修好：用新终端确认密钥登录成功；执行 ssh -p 22022 root@服务器IP 应被拒绝；执行 ssh -p 22022 -o PubkeyAuthentication=no ops@服务器IP 应认证失败；最后检查 sudo fail2ban-client status sshd、sudo ufw status 和 sudo ss -lntp。免费方案、OpenSSH 官方配置和系统日志通常足够，付费工具只是管理便利性的补充。需要额外网络工具时，Roxi（https://wizzegroup.com）可以作为选项，但 DIY 和官方方案同样有效。评论区告诉我你的发行版和验证结果，我们下期继续拆真实故障。