好的，我被迫写一些答案来解决问题。并不是说另一个是完全错误的，但它并没有显示 SSH 协议中正在发生的事情的全貌。

对ssh服务器的身份验证分两步进行。第一个是验证您的公钥是否在authorized_keys文件中，第二个是检查相应私有部分提供的签名是否有效。在服务器调试日志中，您可以看到：

sshd[9951]: debug1: test whether pkalg/pkblob are acceptable
sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9951]: Postponed publickey for vagrant from 10.0.2.2 port 54361 ssh2

参考第一步（test whether pkalg/pkblob are acceptable）。后来一个

sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9950]: Accepted publickey for user from 10.0.2.2 port 54361 ssh2
sshd[9950]: debug3: mm_answer_keyverify: key 0x7f54ce6ac570 signature verified

正在检查密钥私有部分的真实签名。

^{稍微解释一下我在sec.SE上不同问题的回答}

但请注意，第一步不是强制性的。如果您仅指定 private key，或强制使用特定密钥，则跳过第一步，在这种情况下，上述问题是正确的。

上述所有通信（身份验证）都已加密。它在电线上，但不可能在两者之间拦截它。如果您提供此密钥，服务器必须看到它。

如果您担心自己的公钥，请注意，例如 Gitbub 会在 url 上公开公钥https://github.com/<username>.keys。正如一个名字（公众）所说，这没什么大不了的。基于此，有service，它甚至可以在 github 之外识别你，但你仍然需要做第一步（连接到不受信任的服务器，这通常是个坏主意）。

当您连接到 SSH 服务器时，您不会发送您的公钥进行比较。相反，正在发生的事情是客户端/服务器交换使用公钥加密的数据，然后验证客户端确实可以访问相应的私钥。

在 SSHv1 中，服务器使用客户端的公钥加密消息，客户端返回消息的校验和。

在 SSHv2 中，客户端使用客户端的私钥加密消息并发送消息的签名。然后服务器重新创建消息并查看authorized_keys 以验证签名。

本质上，发生的事情是服务器测试您是否可以解密然后回复使用公钥加密的信息。

这些都不是未经加密的“通过网络”发送的，因为在交换这些短语之前启动了加密的 SSH 连接。

要查看更多详细信息，您可以使用 WireShark、Snort、Suricata 或其他数据包嗅探器来检查原始流量。

客户端总是发送整个公钥。这在 RFC-4252 中定义。

SSH_MSG_USERAUTH_REQUEST大多数客户端在第一步中向服务器发送没有签名的。这一步是用来知道可以用哪个私钥登录的，因为可以用密码保护私钥。这样可以避免为未使用的密钥输入密码。

即使跳过了第一步（RFC-4252 允许这样做），也会发送公钥并将签名添加到请求中。

所以在这两种情况下，公钥都被发送到服务器。唯一的区别是，在向服务器查询允许的密钥时，只要服务器不以SSH_MSG_USERAUTH_PK_OK.

目前，大多数客户端不支持SSH_MSG_USERAUTH_REQUEST直接发送带有签名的。

是的，服务器端存在信息泄漏：CVE-2016-20012