ssh 连接过程分析

本文由 简悦 SimpRead 转码， 原文地址 blog.csdn.net 

SSH 建立连接的过程主要分为下面几个阶段：

1. SSH 协议版本协商阶段。SSH 目前包括 SSH1 和 SSH2 两个大版本。
2. 密钥和算法协商阶段，SSH 支持多种加密算法，双方根据自己和对端支持的算法进行协商，最终决定要使用的算法。
3. 认证阶段，服务器对客户端进行身份验证。
4. 会话请求阶段，完成认证后，客户端会向服务器端发送会话请求。
5. 交互会话阶段，会话请求通过后，服务器端和客户端进行信息的交互。

1)SSH 协议版本协商阶段：

1. 客户端通过 TCP 三次握手与服务器的 SSH 端口建立 TCP 连接。
2. 服务器通过建立好的连接向客户端发送一个包含 SSH 版本信息的报文，格式为 “SSH-<SSH 协议大版本号 >.<SSH 协议小版本号 >-< 软件版本号 >”，软件版本号主要用于调试。
3. 客户端收到版本号信息后，如果服务器使用的协议版本号低于自己的，但是客户端能够兼容这个低版本的 SSH 协议，则就使用这个版本进行通信。否则，客户端会使用自己的版本号。
4. 客户端将自己决定使用的版本号发给服务器，服务器判断客户端使用的版本号自己是否支持，从而决定是否能够继续完成 SSH 连接。
5. 如果协商成功，则进入密钥和算法协商阶段。

2. 密钥和算法协商阶段：

1. 服务器端和客户端分别发送算法协商报文给对端，报文中包含自己支持的公钥算法列表，加密算法列表，MAC（Message Authentication Code，消息验证码）算法列表，压缩算法列表等。
2. 和版本协商阶段类似，服务器端和客户端根据自己和对端支持的算法来决定最终要使用的各个算法。
3. 服务器端和客户端利用 Diffie-Hellman 密钥交换算法，主机密钥对等参数，生成共享密钥和会话 ID。会话密钥用于在后续的通信过程中两端对传输的数据进行加密和解密，而会话 ID 用于认证过程。

3. 认证阶段：

1. 客户端向服务器端发送认证请求，请求中包含用户名，认证方法，密码或密钥。
2. 服务器端对客户端进行认证，如果认证失败，则向客户端发送失败消息，其中包含可以再次认证的方法列表。
3. 客户端再次使用支持的认证方法中的一种进行认证，直到达到认证次数上限被服务器终止连接，或者认证成功为止。

4. 会话请求阶段：

1. 服务器等待客户端请求。
2. 认证完成后，客户端想服务器发送会话请求。
3. 服务器处理客户端请求，完成后，会向客户端回复 SSH_SMSG_SUCCESS 报文，双方进入交互会话阶段。如果请求未被成功处理，则服务器返回 SSH_SMSG_FAILURE 报文，表示请求处理失败或者不能识别客户端请求。

5. 交互会话阶段：

1. 客户端将要执行的命令加密发送给服务器。
2. 服务器收到后，解密命令，执行后将结果加密返回客户端。
3. 客户端将返回结果解密后显示到终端上。

下面我们通过客户端（172.31.100.107）抓包来简单说明密钥认证的过程：

报文 1-3：可以看到前三个包是客户端与服务器端三次握手的过程

报文 4：在建立连接后，服务器端将自己支持的 SSH 版本发送给客户端

报文 5：客户端返回给服务器自己要使用的 SSH 版本，如果服务器端不支持这个版本，则到此就终止了 SSH 连接

报文 6：客户端将自己支持的公钥算法列表，加密算法列表，MAC（MessageAuthentication Code，消息验证码）算法列表，压缩算法列表等发送给服务器

报文 7,8：服务器返回 ACK 报文

报文 9：服务器将自己支持的公钥算法列表，加密算法列表，MAC（MessageAuthentication Code，消息验证码）算法列表，压缩算法列表等发送给客户端

报文 10：客户端开始与服务器进行通信的共享密钥的协商，由于前面使用的是 SSH2.0 的协议，所以这里使用的是 Diffie-Hellman-Group-Exchange-SHA 算法（关于 DH-GEX-SHA 算法的原理，可以参考 http://blog.csdn.net/lee244868149/article/details/51790397），在这个报文中，客户端限制了密钥交换参数 Min，Numbers of Bits，Max

报文 11：服务器端收到客户端 DH 请求后，将用于生成公钥的 P 和 G 发送给客户端，P 是一个大素数，满足客户端在报文 10 中的限制，G 是大于 1 的数，不需要特别大，通常取 2 或者 5

报文 12：客户端收到 P 和 G 后，自己生成私钥 a，并根据私钥 a 计算出自己的公钥 e，将 e 发送给服务器端

报文 13：服务器收到客户端发来的 e 后，根据 e 和服务器的私钥 b 可以计算出双方的共享密钥 K，同时服务器通过私钥 b 计算出客户端计算 K 需要的参数 f，将 f 发给客户端

此外，KEY DH host key 为服务器的主机公钥，通常为 RSA 公钥，KEY DH HSignature 为服务器用主机私钥对计算出的哈希值 H 进行签名的结果。

H 的计算方法为：H=hash(V_C||V_S||I_C||I_S||K_S||e||f||K)

其中的参数：

客户端收到服务器发来的 f 后，根据 f 和自己的私钥可以计算出 K，进而计算出 H，同时客户端会利用服务器发送过来的主机公钥 K_S 来验证服务器发送过来的 H 的签名是否有效，如果有效，则客户端在报文 14 中向服务器发送 New Keys 报文，表示双方密钥交换成功，计算出的 H 则作为整个会话的会话 ID。

为了更直观的理解，可以参考下面的计算过程：

后面的数据报文都使用双方协商的共享密钥，所以在抓包结果中就看不到里面的信息了，这里说明一下后续密钥认证的大致过程：

1. 客户端向服务器发送登陆要使用的 IP 地址和用户名，服务器识别对应的客户端公钥（保存在 authorized_keys 中），找到该公钥后，服务器通过公钥加密一段随机字符串，并使用共享密钥加密后发送给客户端。
2. 客户端首先使用共享密钥解密得到使用自己的公钥加密的字符串，再使用自己的私钥解密得到原始字符串，再通过共享密钥加密后发送给服务器。
3. 服务器通过共享密钥解密得到字符串，与之前自己用公钥加密的那个字符串进行对比，如果一致，则说明客户端的私钥与自己的公钥对应，认证成功，否则认证失败。

学习抓包真的能解决好多问题，运维还是一个必备知识

因为经常需要处理上线部署包问题，应用到的地方比较多，觉得有必要把这个学习下。