SSH协议工作过程

SSH的报文交互主要有以下几个阶段:

  1. 连接建立
  2. 版本协商
  3. 算法协商
  4. 密钥交换
  5. 用户认证
  6. 服务请求
  7. 数据传输和连接关闭
1. 建立连接
SSH服务器端在22端口侦听客户端的连接请求, 接收到客户端的连接建立请求后,与客户端进行三次握手,建立起一条TCP连接,后续的所有报文交互都在这个TCP连接之上进行。
2. 版本协商
TCP连接建立之后,服务器和客户端都会向对端发送自己支持的版本号。服务器端和客户端收到对端发送过来的版本后,与本端的版本号进行比较,双方都支持的最高版本号即为协商出的版本号。
版本协商成功后,进入下一个阶段,即算法协商阶段。否则,中断连接

说明:

SSH1.99 为特殊的版本号, 这个版本既可以与SSH2.0 版本互通,又可以与SSH1.5 版本互通。
3. 算法协商

SSH协议报文交互需要使用多种算法:

  1. 用 于 产 生 会 话 密 钥 的 密 钥 交 换 算 法 , 包 括 diffie-hellman-group-exchangesha1、diffie-hellman-group1-sha1 和diffie-hellman-group14-sha1 算法等。
  2. 用于数据信息加密的加密算法,包括 3des-cbc、aes128-cbc 和 des-cbc 加密算法等。
  3. 用于进行数字签名和认证的主机公钥算法,包括 RSA 和 DSA 公钥算法等。
  4. 用于数据完整性保护的 MAC 算法,包括 hmac-md5、hmac-md5-96、hmacsha1 和 hmac-sha1-96 算法等。
由于各种客户端和服务器对这些算法的支持情况不一样,因此需要通过算法协商阶段,使客户端和服务器协商出双方都支持的算法。
SSH协议的算法协商过程为:
  1. 服务器端将自己支持的算法发送到客户端
  2. 双方依次协商每一种算法(密钥交换算法、加密算法等)。每种算法的协商过程均为:从客户端的算法列表中取出第一个算法,在服务器端的列表中查找相应的算法,如果匹配上相同的算法,则该算法协商成功;否则继续从客户端算法列表中取出下一个算法,在服务器端的算法列表中匹配,直到匹配成功。如果客户端支持的算法全部匹配失败,则该算法协商失败。
  3. 某一种算法协商成功后,继续按照上述方法协商其他的算法,直到所有算法(这里是指密钥交换算法、加密算法等)都协商成功;如果某一种算法协商失败,则客户端和服务器之间的算法协商失败,服务器断开与客户端的连接。
4. 密钥交换
加密算法协商成功后,为了保证加解密密钥的安全性,SSH利用密钥交换算法在通信双方安全动态地生成和交互数据的加解密密钥,并能够有效防止第三方窃听加解密密钥。密钥交换算法基本原理是:
  1. 客户端随机选择一个私钥 Xc,1<Xc<p-1,计算出 Yc=g^Xc mod p,将计算出的 Yc 发送给服务器端。其中,p 是一个很大的素数,g 是 p 的素根。p 和g 是双方共有的一对参数,协议允许双方通过协商获得相同的 p 和 g 参数。
  2. 服务器也随机生成一个私钥 Xs,1
  3. 服务器接收到客户端发送过来的 Yc,按照下面的公式计算出密钥:K = (Yc)^Xs mod p
  4. 客户端收到服务器端发送过来的 Ys,同样按照下面的公式计算出密钥:K = (Ys)^Xc mod p

通过上面的方法,客户端和服务器端就可以获得相同的密钥。 由上面的分析可以看出,密钥交换算法的安全性建立在计算离散对数的难度之上。算式Y=g^x mod p中,由X计算Y是很容易的,但是要由Y计算X是非常困难的。在密钥交换算法中对外公开的只有p、g、Yc和Ys,私钥Xc和Xs是保密的,其他用户即便获取了p、g、Yc和Ys也很难推断出私钥Xc和Xs,从而保证了密钥的安全性。

5. 用户认证
用户认证过程为:
(1) 客户端向服务器端发送认证请求报文,其中携带的认证方式为“none”。
(2) 服务器收到 none 方式认证请求,回复认证挑战报文,其中携带服务器支持、且需要该用户完成的认证方式列表。
(3) 客户端从服务器发送给自己的认证方式列表中选择某种认证方式,向服务器发起认证请求,认证请求中包含用户名、认证方法、与该认证方法相关的内容:

  • 密码认证方式中,内容为用户的密码;
  • 公钥认证方式中,内容为用户本地密钥对的公钥部分(公钥验证阶段)或者数字签名(数字签名验证阶段)。
(4)  服务器接收到客户端的认证请求,验证客户端的认证信息:
  • 密码认证方式:服务器将客户端发送的用户名和密码信息,与设备上或远程认证服务器上保存的用户名和密码进行比较,从而判断认证成功或失败。
  • 公钥认证方式:服务器对公钥进行合法性检查,如果不合法,则认证失败;否则,服务器利用数字签名对客户端进行认证,从而判断认证成功或失败。
(5) 服务器根据本端上该用户的配置,以及用户认证的完成情况,决定是否需要
客户端继续认证,分为以下几种情况:

  • 如果该种认证方式认证成功,且该用户不需要继续完成其他认证,则服务器回复认证成功消息,认证过程顺利完成
  • 如果该种认证方式认证成功,但该用户还需要继续完成其他认证,则回复认证失败消息,继续向客户端发出认证挑战,在报文中携带服务器需要客户端继续完成的认证方式列表;
  • 如果该种认证方式认证失败,用户的认证次数尚未到达认证次数的最大值,服务器继续向客户端发送认证挑战;
  • 如果该种认证方式认证失败,且用户的认证次数达到认证次数的最大值,用户认证失败,服务器断开和客户端之间的连接。
6. 服务请求
SSH协议支持多种应用服务。用户成功完成认证后,SSH客户端向服务器端发起服务请求,请求服务器提供某种应用。
服务请求的过程为:
(1) 客户端发送 SSH_MSG_CHANNEL_OPEN 消息,请求与服务器建立会话通道,即 session;
(2) 服 务 器 端 收 到 SSH_MSG_CHANNEL_OPEN 消 息 后 , 如 果 支 持 该 通 道 类型,则回复 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 消息,从而建立会话通道;
(3) 会话通道建立之后,客户端可以申请在通道上进行 shell 或 subsystem 类型的会话,分别对应 SSH 和 SFTP 两种类型的服务。
7. 数据传输和连接关闭
服务请求成功,建立会话后,服务器和客户端可以在该会话上进行数据的传输。客户端将要执行的命令加密后传给服务器,服务器接收到报文,解密后执行该命令,将执行的结果加密发送给客户端,客户端将接收到的结果解密后显示到终端上。
通信结束或用户空闲时间超时后,关闭会话,断开连接。
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: