为什么这条最容易被忽略、却最重要指将服务器主机公钥配置到github上每次 CD 都是一台全新的 runnerGithub~/.ssh/known_hosts 是空的。如果不预置主机公钥就只能用「首次连接即信任」——而每次部署都是一次「首次连接」等于每次都开一个中间人窗口。有人劫持了到那个 IP 的连接你的 runner 会毫无察觉地把私钥用于认证。预置之后工作流里的 StrictHostKeyCheckingyes 才有意义主机公钥对不上就直接断开。预置known_hosts如何防止中间人攻击MITM文章目录不是伪造 IP那么简单是中间人攻击MITM你的 Runner 连接服务器的过程攻击者在哪里动手脚攻击成功后会发生什么最坏的情况是什么预置 known_hosts 后怎么防住的总结在预置known_hosts过程中服务器私钥也要参与为什么必须用到服务器私钥SSH 握手时的真实过程公钥与私钥的配合理清容易混淆的两对密钥第一对服务器主机密钥Host Key—— 证明服务器身份第二对用户登录密钥User Key—— 证明 Runner 身份总结不是伪造 IP那么简单是中间人攻击MITM让我用一个具体场景解释你的 Runner 连接服务器的过程GitHub Runner (美国某个数据中心) │ │ ssh deployyour-server.com │ │ 第一步DNS 解析 your-server.com → 1.2.3.4 │ 第二步TCP 连接 1.2.3.4:22 │ 第三步SSH 握手服务器返回主机公钥 │ 第四步Runner 用私钥认证 │ 第五步执行部署命令 │ ▼ 你的服务器 (1.2.3.4)攻击者在哪里动手脚攻击者不需要入侵你的服务器只需要在网络路径上做手脚场景一DNS 污染Runner 做 DNS 解析时攻击者返回一个假 IPRunner 查询your-server.com 的 IP 是多少 攻击者回答是 6.6.6.6攻击者的服务器场景二BGP 劫持攻击者在互联网路由层面宣告我能到达 1.2.3.0/24 这个网段把流量引到自己那里。这是真实发生过的攻击Cloudflare、AWS 都遭遇过。场景三同网络 ARP 欺骗GitHub 的 Runner 跑在共享数据中心如果同网络有恶意机器可以声称自己是网关截获 Runner 的出站流量。攻击成功后会发生什么Runner 攻击者 (6.6.6.6) 你的服务器 │ │ │ │── SSH 连接 ─────────────────────▶│ │ │ │ │ │◀─ 返回攻击者的主机公钥 ──────────│ │ │ │ │ │ (StrictHostKeyCheckingno) │ │ │ 管他呢接受 │ │ │ │ │ │── 用私钥签名认证 ───────────────▶│ ← 攻击者看到你用哪个密钥、 │ │ 哪个用户名、部署什么代码 │ │ │ │◀─ 攻击者假装是你的服务器 ────────│ │ │ 部署成功 │ │ │ │ │ │ Runner 以为部署成功了 │ 实际上代码根本没到你的服务器 │ 开心地结束了 │最坏的情况是什么攻击者不只是看他可以攻击者能做的后果看到部署的代码泄露你的源码看到你用的 SSH 密钥名和用户名为进一步攻击收集信息返回假的部署成功你以为上线了其实服务器没更新执行恶意操作后假装成功比如在你的服务器上留后门然后告诉你部署正常注意SSH 协议本身不会直接泄露你的私钥私钥只在本地签名不会传输。但攻击者能看到所有其他信息而且如果你的服务器配置了密码认证密码会被捕获。预置 known_hosts 后怎么防住的Runner 攻击者 (6.6.6.6) │ │ │── SSH 连接 ─────────────────────▶│ │ │ │◀─ 返回攻击者的主机公钥 ──────────│ │ │ │ (StrictHostKeyCheckingyes) │ │ 对比 known_hosts │ │ 期望: AAAAC3NzaC1lZDI1... │ │ 实际: BBBBD4NzbC1lZDI1... │ │ │ │ 公钥不匹配断开连接 ❌ │ │ │ │ 部署失败你收到告警 │ │ 攻击者什么也得不到 │注意因为服务器公钥是公开的即使攻击者拿到了服务器真实公钥与Github known_hosts中的服务器公钥对比后一致后续也会验证服务器私钥若私钥不匹配仍会断开连接总结没有预置 known_hosts Runner 对任何自称是你服务器的机器都信任 在公共网络上裸奔 预置 known_hosts StrictHostKeyCheckingyes Runner 只信任持有特定公钥的机器 即使网络被劫持也能立刻发现并断开这不是理论风险。2024 年就有安全研究员演示过通过 DNS 劫持拦截 CI/CD 管道的 SSH 连接。只是大多数人没被攻击过就觉得不会发生在我身上。在预置known_hosts过程中服务器私钥也要参与在这个过程中服务器的私钥也用到了而且起着决定性的作用。只是它永远留在服务器本地不会传输到网络上所以你在 Runner 端感知不到它。如果只用公钥这个安全机制就形同虚设了。下面解释为什么必须用到服务器私钥。为什么必须用到服务器私钥公钥是公开的谁都能复制。假设验证过程只用公钥比对字符串Runner 的 known_hosts 里存着你的服务器公钥 A 攻击者做的事 1. 连上你的服务器把公钥 A 抄下来 2. 放在自己的钓鱼服务器上 3. Runner 连过来时攻击者把公钥 A 发给 Runner 4. Runner 比对哇一模一样信任如果这样攻击者轻易就能冒充你的服务器。所以必须用私钥来自证清白。SSH 握手时的真实过程公钥与私钥的配合在 SSH 握手阶段服务器不仅要把公钥发给 Runner还要证明自己是这个公钥的真正主人你的服务器 GitHub Runner │ │ │── 1. 发送这是我的服务器公钥 ───────────▶ │ │ │ │── 2. 发送这是我用「服务器私钥」 │ │ 对刚才的握手数据做的签名 ──────────▶ │ │ │ │ 3. 验证 │ 用 known_hosts 里的「服务器公钥」 │ 去解密/验证这个签名。 │ │ │ ├── 验证通过 ✅ │ │ 说明对方确实持有对应的私钥 │ │ 身份确认 │ │ │ └── 验证失败 ❌ │ 说明对方只有公钥没有私钥 │ 是冒牌货断开连接结论服务器私钥在服务器端用于签名证明我是我。服务器公钥在 Runner 端known_hosts用于验证签名确认你是你。理清容易混淆的两对密钥在这个 CI/CD 部署场景中其实有两对密钥在同时工作很多人会把它们搞混第一对服务器主机密钥Host Key—— 证明服务器身份作用防止中间人攻击就是你问的这个。服务器私钥存在服务器的/etc/ssh/ssh_host_ed25519_key用于签名。服务器公钥存在 Runner 的~/.ssh/known_hosts用于验证。第二对用户登录密钥User Key—— 证明 Runner 身份作用让服务器知道这个 Runner 有权限登录并部署。Runner 私钥部署私钥存在 GitHub SecretsRunner 用它签名证明自己有权限登录。Runner 公钥部署公钥存在服务器的~/.ssh/authorized_keys服务器用它验证 Runner 的身份。总结密钥存放位置作用是否离开本机服务器私钥你的服务器/etc/ssh/签名握手数据证明服务器身份❌ 绝不离开服务器服务器公钥Runnerknown_hosts验证服务器签名✅ 提前配置到 GitHub Secrets部署私钥GitHub Secrets签名登录请求证明 Runner 权限❌ 绝不离开 Runner部署公钥你的服务器authorized_keys验证 Runner 登录权限✅ 手动添加到服务器所以服务器的私钥不仅用到了而且是整个防伪造机制的核心。没有它参与签名公钥比对就只是一场毫无安全意义的字符串匹配游戏。