复制了 SSH 密钥，还是转发了 agent？两种不同的风险

通过 VPN 使用 SSH 密钥登录，并不意味着私钥已被交给网络运营方，而这一保证比人们听说的要窄。公钥认证发送的是公钥，以及客户端在本地生成的签名。agent 转发是另一种安排，暴露面也不同，它可能在一台你不控制的机器上留下可用的认证能力。你该作何响应，取决于这两种情况中实际发生的是哪一种。

公钥认证会发送什么

在标准公钥方式中，客户端出示公钥，服务器决定是否接受该密钥，客户端再用私钥对质询签名，而私钥留在其文件或 agent 中。跨越网络的只有公钥和由此产生的签名。这次交换中没有任何环节要求服务器、隧道或路径上的任何人持有私密材料。

认证规范定义了这项证明，而私钥并不是请求中的一个字段。

这是关于协议的陈述，不是对每个相关端点的品行背书。主机身份校验仍然必须完好，因为一个无法证明自己身份的服务器，可能在为你不曾设想的目的收集签名。租来的 VM、继承下来的堡垒机和运行陌生扩展的笔记本，是三个彼此独立的信任问题。请把它们与那个确实已经解决的密码学问题分开。

agent 转发会委托什么

agent 转发会打开一条从远程主机回到你机器上 agent 的通道，使该主机上的进程无需持有私钥就能请 agent 签名。密钥留在原处，能力却没有留下。任何能够触及那台远程主机上该转发套接字的东西，在会话存续期间，都可以作为已加载身份之一请求认证操作。这就是被委托的权限，也正因如此，转发值得比交付公钥更窄的策略。

被复制的密钥文件是泄露。被转发的 agent 是授权，两者需要不同的回应。

只为具名的需求和具名的主机启用转发，并检查客户端实际做了什么，而不是配置看起来说了什么。真正起作用的是生效设置，因为主机块会悄悄覆盖全局默认值。同样的道理适用于服务器一侧，当部署从不需要时，它可以完全拒绝转发。

先读证据，再选回应

如果认为私钥文件或等效的签名身份已经暴露，回应应当是按组织流程进行更换和吊销，并从每一个曾经信任它的服务中移除接受。删除一份本地副本，并不会让你看不见的副本失效。

如果担心的是临时的 agent 访问，回应范围更窄：停止不必要的委托，审查涉及的会话与身份，并由事件负责人决定是否需要更换。这里的证据很重要，因为没有观察到外泄，并不能证明认证没有被滥用；而单凭路径变化，也不是密钥被盗的诊断。写下信任了哪个组件、是否启用了转发、实际观察到了什么。然后选择与这份记录相符的回应，而不是最戏剧化的那一个。

ssh-add -l
ssh -G host.example | grep -i forwardagent

在变更前后各运行一次，比较才有意义。先前建立的会话会保留其被授予的委托，无论现在的设置怎么说。

两项不可互换的控制

保护私密材料、限制谁能请求它签名、以及校验对端身份，是三项相关的控制，任何一项都不能替代另一项。一个只移除转发却不检查主机密钥的团队，只修好了半个问题。一个因为路径变化就轮换密钥的团队，什么都没修好。

被攻陷的端点是第四个问题，因为你自己机器上的特权软件能做的远不止观察数据包。

在动手之前，把事件归入那几类，并为每一类指定负责人。保留一份简短记录：信任了什么、委托了什么、验证了什么，因为正是这份记录让下一次复盘变得省事，而不是又一场争论。如果某一类未知，就写未知，而不要假定为良性情形。这种区分是实务性的，不是学术性的：它决定你是更换凭据、吊销会话，还是干脆停止转发。