我是一名网络安全学生，我渴望了解 SSH 会话的基本流程。我尽我所能写下了各个阶段，但需要帮助理解 TCP 握手之后和 Diffie-Hellman 密钥交换之前发生的情况。请帮忙：
会话开始/TCP 握手
客户端通过发起 TCP 握手来开始与服务器的会话。
TCP 会话的非对称加密服务器和客户端反复协商并就 TCP 会话的相互支持的加密协议达成一致。
此时，在协议协商后，我不清楚他们的会话最初是如何加密的。我使用 Wireshark 尝试捕获通过公钥或其他内容发送的客户端或服务器，但只能看到协议版本交换。无论如何，如果可以的话请解释一下这个阶段。
客户端和服务器使用 Diffie-Hellman 算法协商此会话的共享密钥，以建立对称密钥加密会话。客户端和服务器开始生成临时密钥对的过程，使用
- 共享质数
- 加密生成器（通常为 AES）
- 私人质数（作为私钥）。
客户端和服务器使用这三个密钥来生成自己的公钥，该公钥可以从自己的私钥派生出来。
客户端和服务器彼此共享生成的公钥。
客户端和服务器各自使用自己的私钥、对方的公钥以及各自原始的共享质数来生成相同的秘钥。
客户端和服务器使用此密钥作为其共享密钥来加密和解密此会话上的所有未来通信。
在此阶段，客户端和服务器已成功建立对称密钥加密会话，而无需通过网络发送密钥。
如果我还有其他错误，我真的很感激任何澄清。谢谢！
答案1
Diffie-Hellman 密钥交换通过未加密的连接进行，初始算法协商也是如此。这是必需的，因为密钥交换会产生共享秘密，该共享秘密用于生成对称密钥加密所需的秘密。
由于没有加密或完整性检查（例如，使用 AEAD 或 HMAC），因此对会话的这一部分进行身份验证非常重要，因此交换哈希包括共享密钥和各种其他数据，包括客户端和服务器版本、客户端和服务器 Diffie-Hellman 参数，以及提供的初始算法。交换哈希由服务器（以及客户端，如果使用公钥，则与其他数据一起）签名。如果攻击者篡改这些值，则交换哈希将与各方计算的不同，签名将无法验证，并且连接将中止。即使客户端不使用公钥，哈希值和密钥也会不同，并且连接将无法使用（并且会因 MAC 故障而立即失败）。
服务器在发送其 Diffie-Hellman 响应时签署其交换哈希版本。
根据交换哈希和共享秘密，生成加密、MAC 和初始 IV。然后发送消息NEWKEYS并使用新密钥。
然后客户端通过加密连接进行身份验证。这是必需的，因为他们可能使用密码，并且通过未加密的连接使用密码进行身份验证将是一个坏主意。如果客户端使用密钥，他们还会对原始交换哈希以及附加数据进行签名。
请注意，加密密钥、MAC 密钥和 IV 是根据共享密钥生成的；它们不是独立生成的。这意味着需要较少的随机性并确保实现适当的安全级别。 TLS 也做同样的事情。
RFC 4253 中描述了详细信息，RFC 4252 中描述了客户端身份验证。请注意，所描述的许多算法不再使用或已弃用。现代算法在其他 RFC 中描述，或者有时在外部文档中描述（如果它们由实现指定）（即，它们的名称包含符号@）。