通过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

参见RFC 5656，第4节，其中描述了用于SSH的Diffie密钥交换协议。我已经处理了下面这一节的图表：

  Client                                                Server
  ------                                                ------
  Generate ephemeral key pair.
  SSH_MSG_KEX_ECDH_INIT  -------------->

                                  Verify received key is valid.
                                   Generate ephemeral key pair.
                                         Compute shared secret.
                               Generate and sign exchange hash.
                         <------------- SSH_MSG_KEX_ECDH_REPLY

  Verify received key is valid.
  *Verify host key belongs to server.
  Compute shared secret.
  Generate exchange hash.
  Verify server's signature.

  *  It is RECOMMENDED that the client verify that the host key sent
     is the server's host key (for example, using a local database).
     The client MAY accept the host key without verification, but
     doing so will render the protocol insecure against active
     attacks; see the discussion in Section 4.1 of [RFC4251].

因此，会话以未加密的方式开始。密钥交换是通过未加密的连接进行的。此时，客户端和服务器共享一个共享的秘密。然后，将此共享秘密用作临时密钥来加密会话的其余部分。