SSH 代理转发与复制密钥：真正泄露的到底是什么

两件不同的事都被叫作SSH 密钥泄露，但需要的应对并不相同。公钥认证发送的是公钥和一个用私钥生成的签名，因此私钥从来不是请求里的字段。代理转发暴露的是另一件事：能连到你转发的代理的远程主机，可以在完全不持有密钥的情况下请它签名。把两者当成同一件事，结果要么是一次毫无意义的换钥，要么是一份一直开着的委托。

公钥登录传输的是签名，不是密钥

认证交换携带用户的公钥，以及一段覆盖会话数据的签名。服务器用已经信任的密钥校验这份签名，所以私钥那一半可以留在客户端，穿过一条不可信的网络。盯着隧道的 VPN 运营方无论如何都只看到一条加密的 SSH 会话。

这描述的是协议，而不是路径上每个端点的可信程度。主机身份验证要保持完整，因为一个接受任意主机密钥的客户端，放弃的是另一道控制，与这里讨论的不是一回事。被截获的会话和被截获的密钥是两个独立结论，其中只有一个是凭据丢失。在报告里也要把两者写成两句话。

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

第一条命令打印公钥指纹，方便你与服务器列出的值比对。第二条把主机密钥检查写明确，而不是依赖一个没人读过的默认值。改动密钥之前先把两条都跑一遍，好让基线被记录下来。

转发代理，交出的是签名的能力

打开转发后，远程主机上会出现一个套接字，本地代理通过它回应请求。会话期间能用上那个套接字的人，就能以你的身份向接受已加载身份的主机完成认证。做到这一点，不需要任何私钥穿过网络。

暴露出来的是能力，不是文件。所以转发应该属于一个具体的任务和一台具体的主机，而不是笔记本发起的每一次连接。一台只做中继、不带转发代理的跳板机，通常能把这份需要整个去掉。

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

第一条列出代理当前持有哪些身份，把它的套接字交给另一台机器之前值得先看一眼。第二条不经过委托直接连接。第三条演示了经常可以完全取代转发的跳板机做法。

根据手上的证据选择应对

被认为已经暴露的签名身份，要走更换与吊销流程，并把它从信任过它的服务里撤掉接受。只删掉笔记本上的副本，其他副本一个都没动。先从服务侧开始，再清理客户端。

临时的委托问题范围更窄。把不需要的转发停掉，再和事件负责人一起复核它覆盖了哪些会话和身份。密钥更换可能仍要跟进，但那由证据决定，而不是由担心决定。

没有观察到导出，只能证明你担心的那套机制没有出现。它说明不了那个套接字另一端的主机本来还能做什么。

在报告里把几道控制分开写

保护私钥材料，限制谁能让它签名，保持对端身份经过验证。这是三道互相加强的控制，在解释发生了什么时，没有哪一道能替代另一道。

笔记本被攻陷，或上面有一个提权应用，是第三种情况，影响范围大得多。改一条 VPN 路由解决不了它，也不会让一把可能已被从磁盘读走的密钥重新获得信任。

写下当时信任的是哪个组件、转发有没有开着、实际观察到了什么。正是这份记录，让下一次决定站得住脚，而不是对泄露含义的猜测。