项目 5：服务器 SSH 安全初始化

约 3764 字大约 13 分钟

SSH 安全sedDrop-in 配置fail2ban

2026-05-28

项目目标

你刚在云平台购买了一台公网服务器，IP 生效不到 5 分钟，系统日志里已经出现了来自全球各地的暴力破解尝试。

本任务要求你编写一个 init_ssh_security.sh 脚本，完成运维用户创建、SSH 密钥配置、sudo 授权、sshd_config 备份、Drop-in 安全配置下发、禁用密码登录和迁移 SSH 端口等操作。脚本通过 --apply 参数控制是否正式执行（不加即为 dry-run 预览），并内置 sshd -t 语法预检和回滚防呆机制。

一、僵尸网络的暴力破解威胁

当你刚拿到一台拥有公网 IP 的服务器时，你可能觉得它是一片净土。大错特错。

从公网 IP 生效的那一秒起，全球成千上万的僵尸网络和黑客扫描器就已经盯上了它。它们不知疲倦地扫描着默认 SSH 端口 22，使用千万级的密码字典对 root 账户进行疯狂的暴力破解。如果你的密码恰好是 123456 或 admin888，不出半小时，这台服务器就会沦为挖矿肉鸡。

因此，拿到新服务器的第一步永远是安全初始化。它至少做四件事：

步骤	操作	目的
1	创建专用运维用户（非 root）	禁用 root 直接登录，降低爆破面
2	配置 SSH 密钥认证	消灭密码被猜中的可能性
3	迁移 SSH 默认端口（22 → 高位端口）	避开 99% 的盲目扫描
4	禁用密码登录	即使端口被发现，也无法用密码登录

上图是服务器管理面板中的 SSH 登录日志：短时间内就出现了来自不同国家和端口的失败登录记录。这不是"可能发生"的风险，而是公网服务器上线后经常会立刻出现的真实噪声。

二、练习环境：用 Docker 模拟一台"刚买的新服务器"

在第 3 课中，我们已经学会了通过 SSH 把脚本和文件远程发布到另一台机器上——你可以直接复用那些部署手段，把本课脚本传到目标服务器执行。

但如果你手头没有第二台 Linux 机器，可以在 WSL 中用 Docker 快速拉起一台干净的 Ubuntu 容器，把它当成"刚买的服务器"来练手。

# 启动一台 Ubuntu 容器作为练习靶机，映射 SSH 端口 2222
docker run -d --name ssh-target \
  -p 2222:22 \
  ubuntu:22.04 tail -f /dev/null

# 进入容器，安装 SSH 服务
docker exec -it ssh-target bash

# 以下命令在容器内执行：
apt update && apt install -y openssh-server sudo
service ssh start

# 给 root 设置一个临时密码（练习用）
passwd root

现在你有了一个"公网服务器"——通过 ssh -p 2222 root@localhost 就能连进去，后续所有脚本都在这台容器里运行。容器和真实服务器在 SSH 配置层面上完全一致，sshd_config（SSH 服务的主配置文件）、Drop-in 目录（sshd_config.d/，用于存放附加配置片段）、sshd -t（SSH 配置语法检查命令）等操作都可以照常练习。

📌 注意：Docker 容器的 SSH 端口通过 -p 2222:22 映射到了 WSL 的 localhost，你可以直接在 Windows 终端中 ssh -p 2222 root@localhost。

三、为什么不能直接用 `sed` 改配置文件？

安全加固最直接的想法是修改 /etc/ssh/sshd_config（SSH 服务的配置文件），用 Shell 脚本去替换里面的文本。sed 是 Linux 自带的流编辑器（Stream Editor），可以按正则表达式查找并替换文件中的内容：

#!/bin/bash
# 使用 sed 强行修改配置

echo "开始执行 SSH 安全加固..."

# sed -i 表示"直接修改文件"；s/旧文本/新文本/g 表示"全局替换"
sed -i 's/Port 22/Port 38222/g' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config

systemctl restart sshd
echo "加固完毕！"

这段脚本看起来行云流水，但在真实的服务器上运行时，有极大概率毫无作用，甚至直接搞崩 SSH。

sed -i 's/^#Port 22/Port 2222/' sshd_config

输入流 (sshd_config)

# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0

模式空间 (Pattern Space)

等待读取下一行...

输出流 (写入原文件)

点击“下一步”，看看 sed (流编辑器) 是如何在不打开图形编辑器的情况下修改文本的。

陷阱	原因	后果
注释陷阱	默认配置中那行字其实是 `#Port 22`（井号注释），正则 `s/Port 22/` 根本匹配不到	你以为改了端口，实际什么都没动
空格陷阱	配置可能是 `PasswordAuthentication yes`（多个空格或制表符），你的正则会当场失效	密码登录开关没关，加固形同虚设
全局破坏	如果写成 `s/22/38222/g`，其他参数中的 `22`（如 `Protocol 2` 的上下文）也会被错误替换	SSH 彻底崩溃，无法启动

结论：sed 适合简单的一次性文本替换，但不适合修改结构复杂的系统配置文件。这也是为什么高级架构师极度反感在自动化部署中大量使用 sed——它的成功与否完全取决于目标文件里文本的精确写法，而系统配置文件的格式往往因发行版版本不同而变化。

四、Drop-in：不碰主配置的模块化方案

现代 Linux 的系统级组件（如 Systemd、Nginx、OpenSSH）早已为自动化运维做出了架构级妥协：它们全面拥抱了 Drop-in 目录模式。Drop-in 的意思是"插进去"——你可以像往插座里插电器一样，往一个 .d/ 目录里插入自己的配置文件，而不需要修改原有的主文件。

在 /etc/ssh/ 下除了庞大的 sshd_config 主文件，还有一个 sshd_config.d/ 文件夹（文件夹名末尾的 .d 代表 Directory）。主配置顶部有一行 Include /etc/ssh/sshd_config.d/*.conf——意思是"把 sshd_config.d/ 目录下所有 .conf 文件的内容也一起读进来"。这意味着我们根本不需要动主配置，只需要在这个文件夹里丢一个自定义的 .conf 碎片文件，OpenSSH 服务（sshd，即 SSH Daemon，负责接受远程连接的那个后台进程）启动时就会自动拼装并覆盖默认值。

问题：通过向 .d/ 子目录追加配置文件而不修改主配置的模式被称作什么模式？（首字母大写，包含连字符）

Drop-in 的三大优势：

优势	说明
零破坏	优先不动主配置，日常变更全通过 Drop-in 文件
可追溯	文件名带编号（如 `99-custom-security.conf`），一眼就知道是谁加的
秒回滚	`rm` 掉碎片文件然后重启，瞬间恢复

⚠️ 解锁的脚本是教学演示版。最终的正式脚本会在写入新配置前自动清理旧的演示文件，你不必担心两个 Drop-in 冲突。

五、进阶防护：fail2ban 自动封禁

即使改了端口，攻击者仍可能扫描到并尝试暴力破解。我们需要在底层拉起一道自动封禁的防线。

Linux 的身份认证统一由 PAM（Pluggable Authentication Modules，可插拔认证模块） 管理。简单理解：当任何一个程序（SSH、su 切换用户、甚至图形界面的锁屏）想要验证"你是谁"时，它们都不会自己去读密码文件，而是把这个请求扔给 PAM。PAM 像一个安检闸机——你可以不断往上面加安检模块，比如"密码错误 3 次就锁定账户"。

我们使用 fail2ban 这个工具来做这件事：它会持续盯着 /var/log/auth.log（系统认证日志），一旦发现某个 IP 在短时间内多次登录失败，就自动调用 iptables（Linux 内核自带的防火墙）把这个 IP 暂时拉黑。

问题：Linux 中常用的监控日志并自动封禁恶意爆破 IP 的开源工具叫什么？

📌 本课主线是 SSH 安全初始化（用户、密钥、Drop-in 配置），fail2ban 是可选增强。时间紧张可以只学前四节 + 第六节最终脚本。

六、SRE 回滚铁律与最终版脚本

现在脚本能 Drop-in 改配置、fail2ban 防爆破了。但如果执行 systemctl restart sshd 时，新端口被云安全组拦截了呢？

重启后新连接进不来，如果你又把当前的旧会话关了，就永远失去了这台机器。（已建立的旧 SSH 会话通常不会因重启而断开——这正是 SRE 要求必须保留旧终端的原因。）

💾

1. 备份配置

👤

2. 建运维用户

🔑

3. 导入公钥

🛡️

4. 禁用密码/换端口

✅

5. 测试与重启

点击“开始加固”，观察 SSH 安全初始化的绝对时序规则。

三条不可逾越的红线

重启前，必须先 sshd -t 语法预检 —— 配置文件多一个空格都可能导致服务起不来
配置生效时，绝不关闭当前正在连接的旧 SSH 会话 —— 这是最后的救命稻草
必须打开第二个终端，用新端口尝试登录 —— 新连接成功了，才算真正交付

Terminal 1 (Root, 保持开启)

root@server:~# systemctl restart sshd

Terminal 2 (验证新配置)

修改网络和认证配置时，最怕把自己“锁”在门外。点击“模拟”，看看如何自救。

解锁最终版脚本

在下方输入 SSH 服务用于配置文件语法预检的诊断参数（提示：sshd 加上什么参数可以只检查配置而不真正重启服务？），解锁具备完整 dry-run、备份、回滚能力的正式脚本：

问题：在不重启服务的情况下，让 SSHD 检查配置文件语法错误的命令是什么？

将解锁的代码保存为 init_ssh_security.sh，赋予执行权限：chmod +x init_ssh_security.sh。

七、运行与验证

7.1 生成密钥对（在客户端执行）

# ssh-keygen：生成 SSH 密钥对
#   -t ed25519：使用 Ed25519 算法（比 RSA 更快更安全，推荐）
#   -f ~/.ssh/ops_ed25519：私钥保存路径（公钥会自动加 .pub 后缀）
#   -N ""：不设置私钥密码
ssh-keygen -t ed25519 -f ~/.ssh/ops_ed25519 -N ""

执行后会在 ~/.ssh/ 目录下生成两个文件：

ops_ed25519：私钥（绝密，存放在你自己的电脑上，不要传给任何人）
ops_ed25519.pub：公钥（可以放心传到任何服务器上）

7.2 将公钥传到服务器

# 方式一：scp 上传（推荐）
# scp 是 Secure Copy 的缩写，通过 SSH 协议安全地复制文件
scp ~/.ssh/ops_ed25519.pub root@localhost:/tmp/ops_key.pub

# 方式二：手动复制粘贴
cat ~/.ssh/ops_ed25519.pub   # cat 显示文件内容；复制输出
ssh root@localhost            # ssh 连接到服务器
cat > /tmp/ops_key.pub        # 粘贴后按 Ctrl+D 保存文件

7.3 执行脚本

# 先 dry-run 预览（不加 --apply）
sudo bash init_ssh_security.sh \
  --user ops --port 2222 \
  --public-key-file /tmp/ops_key.pub

# 确认没问题后正式执行
sudo bash init_ssh_security.sh \
  --user ops --port 2222 \
  --public-key-file /tmp/ops_key.pub \
  --apply

7.4 新终端验证登录

# 保留当前终端！新开一个窗口
ssh -p 2222 -i ~/.ssh/ops_ed25519 ops@localhost

# 确认配置生效
sudo sshd -T | grep -E '^(port|pubkeyauthentication|passwordauthentication|permitrootlogin)'

⚠️ 如果是用 Docker 模拟的靶机，ops@localhost 就是正确的验证方式——你从 Windows/WSL 终端连接到了容器内部。

7.5 提交物清单

将以下文件打包压缩后提交：

文件	说明	验证方法
`init_ssh_security.sh`	最终版安全初始化脚本	支持 `--help` 和 `--apply`
dry-run 输出截图	不加 `--apply` 的预览结果	显示将要执行的所有命令
`sshd -T` 输出截图	配置生效后的 `grep` 结果	显示端口、密钥认证等四行配置
新终端登录截图	用新端口 + 密钥登录成功	显示 `ssh -p 2222 ops@...`
回滚说明	一句话总结	备份路径 + drop-in 文件路径 + 回滚命令

随堂提问

sshd -t 和 sshd -T 有什么区别？
为什么 SRE 在重启 SSH 时绝对不能关闭旧终端？

八、故障排查工具箱

现象	根因	排查方法
`Bad configuration option`	Drop-in 文件中存在拼写错误	检查 `/etc/ssh/sshd_config.d/` 下配置文件的语法
改完端口后连不上了	云安全组或本地防火墙未放行新端口；Docker 场景检查 `-p` 端口映射是否正确	登录云控制台放行端口；`sudo ufw allow 2222/tcp`
`sed` 脚本导致 SSH 崩溃	正则表达式破坏了配置文件结构	用 VNC/控制台进入，从备份恢复 `sshd_config`
密钥登录失败 `Permission denied`	公钥写入错误或文件权限不对	`ls -la ~/.ssh/` 确认 `authorized_keys` 权限为 600，`.ssh` 为 700
`sudo: no tty present`	sudoers 配置缺少 `NOPASSWD`	检查 `/etc/sudoers.d/ops` 中是否有 `NOPASSWD:ALL`

九、进阶验收标准

验收维度	达标要求
正则陷阱认知	能举例说明 `sed` 修改 `sshd_config` 的三个常见失败场景（注释、空格、全局破坏）
Drop-in 思想	能用自己的话解释为什么向 `.d/` 目录追加文件比修改主配置更安全，能说出至少两个理由
SRE 回滚铁律	能口述 SSH 服务变更的三条不可逾越的红线，并能解释 `sshd -t` 和 `sshd -T` 的区别
脚本实操	能独立运行脚本完成 dry-run → 正式执行 → 新端口登录的完整流程，并在故障排查表中定位自己遇到的问题

十、深度探索任务

以下任务不强制提交，但完成后会让你真正理解本课的设计思想：

探索任务 1：手动制造一个配置错误

在 Drop-in 配置文件中故意写一个语法错误（如把 Port 写成 Portt），然后运行 sshd -t。观察 SSHD 是否能检测到这个错误。这个实验证明了为什么 sshd -t 是 SRE 回滚铁律的第一步。

探索任务 2：对比 sed 和 Drop-in 的恢复速度

先用 sed -i 修改 sshd_config，然后模拟"配错了需要恢复"的场景。再用 Drop-in 方式（rm 99-custom-security.conf）模拟同样的恢复。比较两种方式各自需要几步操作、各有什么风险。

探索任务 3：分析 fail2ban 的封禁日志

📌 前提：本任务需要在 未禁用密码登录的测试环境 中执行。如果你已经运行了最终版脚本（PasswordAuthentication no），SSH 客户端不会进入输密码流程，fail2ban 自然收不到失败记录。建议在运行最终脚本前，先用一个未加固的测试环境完成本任务。

启动 fail2ban 后，故意用错误密码尝试 SSH 登录 3 次。然后执行 sudo fail2ban-client status sshd 查看自己的 IP 是否已被封禁。再用 sudo iptables -L -n 查看 fail2ban 自动添加的防火墙规则。