通过SSH连接时，Diffie-Hellman密钥交换是在未加密的TCP会话上进行，还是在交换之前进行加密？

Question

我是一名网络安全专业的学生，我渴望了解SSH会话的基本过程。我尽我所能写下了各个阶段，但需要帮助理解TCP握手之后和Diffie-Hellman密钥交换之前发生了什么。请帮助：

会话启动/TCP握手

1. 客户端通过发起TCP握手开始与服务器的会话。TCP会话的辅助加密
2. 服务器和客户端之间来回协商，并为TCP会话商定一个相互支持的加密协议。此时，协议后协商，我不清楚他们的会话最初是如何被加密的.我使用Wireshark试图捕获客户端或服务器发送他们的公钥或其他东西，但只能看到协议版本交换。无论如何，如果您使用Diffie-Hellman算法协商此会话的共享密钥，请解释此阶段，以便建立对称密钥加密会话。
3. 客户机和服务器使用开始生成临时密钥对的过程
   1. 共享素数
   2. 加密生成器(典型的AES)
   3. 私有素数(作为私钥)。

4. 客户机和服务器使用这三种方法分别生成可以从自己的私钥派生的自己的公钥。
5. 客户端和服务器共享各自生成的公钥。
6. 客户机和服务器各自使用自己的私钥、对方的公钥和原始共享素数来生成相同的密钥。
7. 客户端和服务器使用此密钥作为他们的共享密钥来加密和解密此会话上的所有未来通信。

在此阶段，客户端和服务器已经成功地建立了对称密钥加密会话，而不需要通过网络发送密钥。

，如果我还有什么不对的地方，我会非常感谢你的澄清。谢谢！

Answer 1

Diffie-Hellman密钥交换是在未加密的连接上进行的，初始算法协商也是如此。这是必需的，因为密钥交换会产生一个共享秘密，用于生成对称密钥加密所需的秘密。

由于没有加密或完整性检查(例如，使用AEAD或HMAC)，因此必须对会话的这一部分进行身份验证，因此exchange散列包括共享秘密和各种其他数据，包括客户端和服务器版本、客户端和服务器Diffie-Hellman参数以及初始算法提供的数据。exchange哈希由服务器(如果使用公钥，则与客户端以及其他数据一起)签名。如果攻击者篡改了这些值，exchange散列将与各方计算的值不同，签名将无法验证，连接将被中止。即使客户端不使用公钥，哈希和密钥也会有所不同，连接也将不可用(并且会因MAC故障而迅速失败)。

服务器在发送Diffie-Hellman响应时签名其版本的exchange散列。

从交换散列和共享秘密生成加密、MAC和初始IV。然后发送一个NEWKEYS消息，然后使用新的键。

然后，客户端通过加密的连接进行身份验证。这是必需的，因为他们可能正在使用密码，通过未加密的连接使用密码进行身份验证是个坏主意。如果客户端使用密钥，则还对原始exchange散列和其他数据进行签名。

请注意，加密密钥、MAC密钥和IVs是从共享秘密生成的；它们不是独立生成的。这意味着所需的随机性较小，并确保实现了适当程度的安全性。做同样的事。

血淋淋的细节在RFC 4253中描述，客户身份验证在RFC 4252中描述。请注意，所描述的许多算法不再使用或不再推荐。现代算法是在其他RFC中描述的，如果它们是由实现指定的(也就是说，它们的名称包含@符号)，则有时在外部文档中描述它们。