了解 wireshark 捕获 ssh 密钥交换

Question 1

首先，你应该理解 Diffie-Hellman 交换的概念。它允许在两个端点之间建立具有以下特征的通道：

防止窃听。嗅探频道的人无法解密。
Diffie-Hellman 无法防御中间人攻击。此类攻击可通过验证主机密钥来防止。验证是在 DH 交换后完成的，因此已加密，目前无法使用 wireshark 进行分析。
它生成的随机数不能由任何一方单独确定，而需要双方共同确定。这对我来说是一个有趣的概念。
以下是来自维基百科文章的简化交换结构：
1. 让G是有限循环群的已知公共数。
2. Alice 选择一个随机自然数A并将 g ^a发送给 Bob。
3. Bob 选择一个随机自然数b并将 g ^b发送给 Alice。
4. Alice 计算 (g ^b ) ^a = g ^ab
5. Bob 计算 (g ^a ) ^b = g ^ab

结果他们生成了一个安全的随机秘密g ^ab。

现在进行 WIRESHARK 捕获！

SSHv2 客户端：密钥交换初始化

几个参数协商，如压缩和一些加密算法。
SSHv2 服务器：密钥交换初始化

回复上面的内容
SSHv2 客户端：Diffie-Hellman 密钥交换初始化

有关数学组的 DH 参数的协商。（有关更多详细信息，请参阅 RFC4419 第 3 节）。
SSHv2 服务器：Diffie-Hellman 密钥交换回复

回复上面的内容。
SSHv2 客户端：Diffie-Hellman GEX Init

DH 的首次实际交换。按照 wikipedia 符号，这是步骤 2（Alice 发送 g ^a）。
SSHv2 服务器：Diffie-Hellman GEX 答复

交换完成（Bob 发送 g ^b）。

收到此数据包后，两个对等点都知道密钥（g ^ab）并使用它建立一个伪安全通道（可以防止随意窃听，但不能防止中间人攻击）。
SSHv2 客户端：新密钥

在我看来，这看起来像是一条简单的确认信息。它很小，不包含任何重要数据。

好的，我想这之后还有很多事情要做（服务器公钥验证、用户身份验证、为 shell/sftp/scp/tunnels 建立数据通道等）。我不知道确切的细节，（不幸）幸运的是，所有这些都是加密的。

有用的参考资料：

Answer

首先，你应该理解 Diffie-Hellman 交换的概念。它允许在两个端点之间建立具有以下特征的通道：

防止窃听。嗅探频道的人无法解密。
Diffie-Hellman 无法防御中间人攻击。此类攻击可通过验证主机密钥来防止。验证是在 DH 交换后完成的，因此已加密，目前无法使用 wireshark 进行分析。
它生成的随机数不能由任何一方单独确定，而需要双方共同确定。这对我来说是一个有趣的概念。
以下是来自维基百科文章的简化交换结构：
1. 让G是有限循环群的已知公共数。
2. Alice 选择一个随机自然数A并将 g ^a发送给 Bob。
3. Bob 选择一个随机自然数b并将 g ^b发送给 Alice。
4. Alice 计算 (g ^b ) ^a = g ^ab
5. Bob 计算 (g ^a ) ^b = g ^ab

结果他们生成了一个安全的随机秘密g ^ab。

现在进行 WIRESHARK 捕获！

SSHv2 客户端：密钥交换初始化

几个参数协商，如压缩和一些加密算法。
SSHv2 服务器：密钥交换初始化

回复上面的内容
SSHv2 客户端：Diffie-Hellman 密钥交换初始化

有关数学组的 DH 参数的协商。（有关更多详细信息，请参阅 RFC4419 第 3 节）。
SSHv2 服务器：Diffie-Hellman 密钥交换回复

回复上面的内容。
SSHv2 客户端：Diffie-Hellman GEX Init

DH 的首次实际交换。按照 wikipedia 符号，这是步骤 2（Alice 发送 g ^a）。
SSHv2 服务器：Diffie-Hellman GEX 答复

交换完成（Bob 发送 g ^b）。

收到此数据包后，两个对等点都知道密钥（g ^ab）并使用它建立一个伪安全通道（可以防止随意窃听，但不能防止中间人攻击）。
SSHv2 客户端：新密钥

在我看来，这看起来像是一条简单的确认信息。它很小，不包含任何重要数据。

好的，我想这之后还有很多事情要做（服务器公钥验证、用户身份验证、为 shell/sftp/scp/tunnels 建立数据通道等）。我不知道确切的细节，（不幸）幸运的是，所有这些都是加密的。

有用的参考资料：

Question 2

客户端和服务器首先互相发送他们正在使用的协议和软件版本。

SSHv2 Client: Key Exchange Init

在这里，客户端按优先顺序告诉服务器它支持的每个功能（加密、MAC、密钥交换、主机认证、压缩）的算法。

SSHv2 Server: Key Exchange Init

服务器也一样。注意，它可以在收到来自客户端的消息之前发送此消息。

从两个算法列表中，客户端和服务器独立计算相同的密码套件。例如，它们选择相同的 kex 交换算法（并且紧接着进行）。

SSHv2 Client: Diffie-Hellman Key Exchange Init
SSHv2 Server: Diffie-Hellman Key Exchange Reply
SSHv2 Client: Diffie-Hellman GEX Init
SSHv2 Server: Diffie-Hellman GEX Reply

Diffie-Hellman 密钥交换使客户端和服务器最终获得一个网络上的观察者无法猜测的共享秘密。例如，他们将从这个秘密中派生出加密算法的密钥。

请注意，服务器的回复还包含其公共主机密钥（或证书）。如果它是一个公钥，而客户端从未见过它，客户端通常会询问用户是否应该信任它：

无法确定主机“debian.org (130.89.148.14)”的真实性。ED25519
密钥指纹为 SHA256:bNnjFMvzsNhkwzRHwGRbTIUM4XzUjlLrBl/7MzCbndw。

SSHv2 Client: New Keys

随着新钥匙消息，客户端的意思是：

嘿，服务器！我接下来的所有消息都将使用我们刚刚协商好的密码。

服务器还必须发送新钥匙向客户发送消息。

我的主要参考是 SSH 传输协议的 RFC：https://www.rfc-editor.org/rfc/rfc4253。这是 SSH 的最低层，所有其他 SSH 服务（用户身份验证、shell、X11 转发等）都基于此层。

Answer