Linux SSH建立连接过程分析



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. 客户端再次使用支持的认证方法中的一种进行认证，直到达到认证次数上限被服务器终止连接，或者认证成功为止。

SSH支持的两种认证方式：

1. 密码认证：客户端通过用户名/密码进行认证，将使用会话密钥加密后的用户名和密码发送给服务器，服务器解密后与系统保存的用户名和密码进行对比，并向客户端返回认证成功或失败的消息。
2. 密钥认证：采用数字签名来进行认证，目前可以通过RSA和DSA两种算法实现数字签名，客户端通过用户名，公钥以及公钥算法等信息来与服务器完成验证。

 

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)

其中的参数：

类型

值

说明

string

V_C

客户端的初始报文（版本信息：SSH-2.0-xxx，不含结尾的CR和LF）

string

V_S

服务器的初始报文

string

I_C

客户端 SSH_MSG_KEX_INIT的有效载荷（不含开头的数据长度值）

string

I_S

服务器的同上

string

K_S

主机秘钥（dh gex reply（33)过程服务器发送host key (RSA公钥)）

mpint

e

客户端DH公钥

mpint

f

服务器DH公钥

mpint

K

共同DH计算结果

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

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

 

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

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