问如何防止加载到ssh代理中的密钥被发送到特定(不安全)服务器？

EN

你在这里有几个误解。

首先，公共/私有密钥区的全部要点是您不向服务器发送私钥。您的密钥唯一的用途是签名消息；在SSH协议期间，服务器在任何时候都不会得到您的私钥。即使您使用代理转发(它允许您从第一个服务器使用您的密钥登录到其他服务器)，服务器也不会获得您的私钥:它只是将内容传递给您计算机上的ssh-agent，后者对它们进行签名，并将签名发送回第一台服务器发送。

其次，在这种情况下，“密钥交换”并不意味着“传递密钥”，而是“建立共享的秘密”。Diffie-Hellman的工作方式是客户端和服务器生成一个新的密钥，这与他们以前可能拥有的任何密钥完全无关。长期键(即存储在文件中的键盘)只用于签署密钥交换的元素，以便您知道您正在与您认为正在交谈的服务器对话。

第三，SSH中的密钥交换与客户端密钥(id_rsa和类似的)完全无关。服务器在密钥交换期间使用主机密钥进行身份验证，但在密钥交换期间不会发生客户端身份验证。客户端密钥的所有用途都是在密钥交换之后(以及在发送要登录的用户名之后)对特定的字符串进行签名，以证明您可以使用与该用户的授权公钥相对应的私钥进行签名。密钥交换算法与客户端密钥无关。

因此，弱密钥交换不会给私钥安全带来任何问题。这种安全性不依赖于强大的密钥交换。唯一可以做的攻击是利用代理转发，但只有在以下情况下才能工作：( a)您首先启用了代理转发，b)您仍然连接(断开=不再有代理转发)。

第四，实际上我不知道使用SHA-1进行交换哈希的问题。沙-1对碰撞攻击很弱，这意味着创建两个值相同的东西比它应该要容易得多。但是要成功地实现MITM连接，您需要进行第二次预图像攻击，这意味着要创建一个与您无法控制的东西的冲突。在碰撞攻击中，您控制碰撞的两部分，这是一个问题，如果您正在签名某个东西，攻击者可以控制您要签名的内容，在这种情况下，攻击者可以创建一个碰撞对，让您签名一件东西，并使用它作为另一件东西的签名。虽然它通常更好地远离它，认为它不安全的情况下，只需要第二-图像前阻力有点大。

理解风险:跳转主机访问其他资源

但是，如果我已经将我的常规密钥添加到ssh-agent中，那么我希望更安全的密钥仍将通过潜在的不安全密钥交换发送。

在您描述的场景中，关键材料的暴露实际上并不是风险。代理转发的主要风险是，任何可以访问您的帐户和/或您连接到的远程服务器上的套接字连接的人，都能够在该机器上使用您的转发代理使其成为使用您的特权跳转到其他资源的主机。换句话说，风险并不是他们获得了对您的密钥的访问权；而是他们可以使用您的转发代理来扩展对其他帐户、服务或主机的访问，在这些帐户、服务或主机中，基于代理的远程公钥身份验证足以授予访问权限。

禁用持久连接和代理转发

如果您不完全信任连接到的服务器，则可以使用命令行标志或存储的~/.ssh/config文件设置来关闭每个主机的代理转发。例如，下面的配置默认是允许代理转发，但是在连接到特定的不受信任主机时，转发和连接共享将被关闭：

Host untrusted-host.example.com
    ControlPersist              no
    ForwardAgent                no

Host *
    Compression                 yes
    ControlMaster               auto
    ControlPath                 ~/.ssh/main-%r@%h:%p
    ControlPersist              yes
    ForwardAgent                yes

基本上，Host *定义的任何内容都是默认设置，而特定主机的设置优先。在上面的示例中，OpenSSH被配置为在默认情况下转发SSH代理套接字，并在后台保持活动连接处于打开状态，以允许对SSH会话进行修改。通过关闭不受信任主机的ControlPersist和ForwardAgent，可以覆盖该特定主机的默认值。

所有这些设置(以及更多的设置)都记录在man 5 ssh_config for OpenSSH中。OpenSSH命令行客户端还允许您使用-o标志来细化或覆盖配置文件选项，如man 1 ssh中所记录的那样，但是配置文件文档在解释每个选项的实际操作方面做得更好。

其他SSH客户端将有其他配置机制，但是任何正确实现代理转发的客户端都应该以类似的方式工作，即使用户配置的机制不同。这至少会让您指向正确的方向，并使您能够决定是否信任给定的服务器来访问您的转发代理。