Linux 云服务器安全加固入门：SSH 密钥登录、防火墙与 fail2ban 实践

简介

云服务器加固的重点不是堆工具，而是减少暴露面并保留恢复路径。本文以 Ubuntu/Debian 为主，补充 firewalld 思路。请先准备普通 sudo 用户、控制台远程登录及配置备份，始终保留当前 SSH 会话。示例端口 22222 不是安全边界，操作须按发行版调整。

修改SSH配置

不要立即关闭旧入口：先完成下节密钥配置并验证登录，再修改服务端配置。备份 /etc/ssh/sshd_config，检查 Include 文件及 Match 块，避免重复设置。目标如下：

Port 22222
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

禁用交互式认证前，确认没有依赖它的多因素认证。改端口仅减少扫描噪声，不能替代密钥认证。先放行新端口，再检查语法并重载：

sudo sshd -t
sudo sshd -T
sudo systemctl reload ssh
sudo ss -lntp

RHEL 系通常用 sshd 服务；SELinux 开启时，应为新端口设置 ssh_port_t 类型，不能简单关闭 SELinux。启用 socket activation 的系统还应检查 ssh.socket，不能只看配置文件。

生成并配置密钥

在客户端生成密钥，为私钥设置强口令；私钥不得上传服务器或发布。先沿用原端口安装公钥到普通用户，再另开终端验证。SERVER_HOST 和 loginuser 都是占位符：

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/cloud_ed25519
ssh-copy-id -i ~/.ssh/cloud_ed25519.pub loginuser@SERVER_HOST
ssh -i ~/.ssh/cloud_ed25519 loginuser@SERVER_HOST

服务端 ~/.ssh 权限应为 700，authorized_keys 为 600，归属登录用户。确认公钥认证成功、sudo 可用后，才禁用密码和 root 登录。

ufw/firewalld 规则

两套工具选一种，不混用。UFW 先保留旧入口、允许新端口，再启用；业务端口按需放行：

sudo ufw allow 22/tcp
sudo ufw allow 22222/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

firewalld 先确认活动 zone，以下仅适用于 public：

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22222/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all

验证新连接后再删除旧规则。如使用 IPv6，也要同步检查其监听和访问策略。

华为云安全组配合

主机防火墙与华为云安全组是两道独立检查。为实例关联的安全组添加 TCP 新 SSH 端口入方向规则，来源限定为自己的出口地址段，不默认向全网开放。先验证新连接，再移除旧端口规则；数据库、管理后台不要直接暴露公网。

安装配置 fail2ban

从发行版仓库安装：

sudo apt update
sudo apt install fail2ban

在 /etc/fail2ban/jail.d/sshd.local 写入：

[sshd]
enabled = true
port = 22222
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

使用 journal 的系统可选 systemd 后端；若记录到文件，应调整后端和日志路径。封禁动作须适配实际防火墙，不能只看到服务启动就认为生效：

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

验证与注意事项

另开终端用密钥连接新端口：

ssh -p 22222 -i ~/.ssh/cloud_ed25519 loginuser@SERVER_HOST

检查有效配置、监听端口、安全组和 jail 状态，确认密码及 root 登录已被禁止。不在唯一管理连接上故意触发封禁。保留原会话直到复测结束，异常时通过控制台恢复备份。不要发布真实地址、私钥或含敏感信息的日志。

排错时按层定位，而非反复重启：连接超时通常先查安全组、路由及防火墙；连接被拒绝先查监听；认证失败再查账号、公钥权限和服务日志。使用 ssh -v 观察客户端认证过程，但分享输出前先脱敏。配置回滚也要分步进行，每次只改一层并记录结果。

对于多人维护的服务器，应给每位成员分配独立普通账号和公钥，离职时删除对应授权，而不是共享私钥。定期清理不再使用的授权项，限制 sudo 权限，保存变更记录。服务器重建时核对主机指纹，不要为省事关闭主机身份校验；私钥口令和磁盘保护也很重要。

fail2ban 属于补充措施，不能修复弱口令或服务漏洞。若安全组已只允许可信管理网段，暴露面会更小；动态出口用户需提前规划变更或使用受控管理通道。任何自动封禁规则都可能误伤，须了解解封步骤并保留控制台入口。升级系统后重新核验配置和规则，避免默认值变化让防护失效。

总结

顺序比命令更重要：准备恢复通道、配置密钥、双层网络放行、调整 SSH、验证后收紧旧入口，最后用 fail2ban 降低恶意重试。持续更新系统、审计日志并演练恢复，才能让加固长期有效。