SSH通信协议浅析

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

SSH通信协议浅析

第一部分:协议概览

整个通讯过程中,经过下面几个阶段协商实现认证连接。

第一阶段:

由客户端向服务器发出 TCP 连接请求。TCP 连接建立后,客户端进入等待,服务器向客户端发送第一个报文,宣告自己的版本号,包括协议版本号和软件版本号。协议版本号由主版本号和次版本号两部分组成。它和软件版本号一起构成形如:

"SSH-<主协议版本号>.<次协议版本号>-<软件版本号>\n"

的字符串。其中软件版本号字符串的最大长度为40个字节,仅供调试使用。客户端接到报文后,回送一个报文,内容也是版本号。客户端响应报文里的协议版本 号这样来决定:当与客户端相比服务器的版本

号较低时,如果客户端有特定的代码来模拟,则它发送较低的版本号;如果它不能,则发送自己的版本号。当与客户端 相比服务器的版本号较高时,客户端发送自己的较低的版本号。按约定,如果协议改变后与以

前的相兼容,主协议版本号不变;如果不相兼容,则主主协议版本号升高。

服务器接到客户端送来的协议版本号后,把它与自己的进行比较,决定能否与客户端一起工作。如果不能,则断开TCP 连接;如果能,则按照二进制数据包协议发送第一个二进制数据包,双方以较低的协议版

本来一起工作。到此为止,这两个报文只是简单的字符串,你我等凡人直接 可读。

第二阶段:

协商解决版本问题后,双方就开始采用二进制数据包进行通讯。由服务器向客户端发送第一 个包,内

容为自己的 RSA主机密钥(host key)的公钥部分、RSA服务密钥(server key)的公钥部分、支持的加密方法、

支持的认证方法、次协议版本标志、以及一个 64 位的随机数(cookie)。这个包没有加密,是明文发送的。

客户端接收包后,依据这两把密钥和被称为cookie的 64 位随机数计算出会话号(session id)和用于加密的会

话密钥(session key)。随后客户端回送一个包给服务器,内容为选用的加密方法、cookie的拷贝、客户端次

协议版本标志、以及用服务器的主机密钥的公钥部分和服务密 钥的公钥部分进行加密的用于服务器计算会

话密钥的32 字节随机字串。除这个用于服务器计算会话密钥的 32字节随机字串外,这个包的其他内容都

没有加密。之后,双方的通讯就是加密的了,服务器向客户端发第二个包(双方通讯中的第一个加密的包)证实客户端的 包已收到。

第三阶段: 

双方随后进入认证阶段。可以选用的认证的方法有:

(1) ~/.rhosts 或 /etc/hosts.equiv 认证(缺省配置时不容许使用它);

(2) 用 RSA 改进的 ~/.rhosts 或 /etc/hosts.equiv 认证;

(3) RSA 认证;

(4) 口令认证。

如果是使用 ~/.rhosts 或 /etc/hosts.equiv 进行认证,客户端使用的端口号必须小于1024。

认证的第一步是客户端向服务器发 SSH_C M S G_U S E R 包声明用户名,服务器检查该用户是否存在,确定是否需要进行认证。如果用户存在,并且不需要认证,服务器回送一个SSH_S M S G_S U CC E SS 包,认证

完成。否则,服务器会送一个 SSH_S M S G_F A ILU R E 包,表示或是用户不存在,或是需要进行认证。注意,如果用户不存在,服务器仍然保持读取从客户端发来的任何包。除了对类型为

SSH_M S G_DI SC ONNE CT、SSH_M S G_IGNO R E 以及 SSH_M S G_DEBUG 的包外,对任何类型的包都以

SSH_S M S G_F A ILU R E 包。用这种方式,客户端无法确定用户究竟是否存在。

如果用户存在但需要进行认证,进入认证的 第二步。客户端接到服务器发来的 SSH_S M S G_F A ILU R E

包后,不停地向服务器发包申请用各种不同的方法进行认证,直到时限已到服务器关闭连接为止。时限一般设定为 5 分钟。对任何一个申请,如果服务器接受,就以 SSH_S M S G_S U CC E SS 包回应;如果不接受,或者是无法识别,则以 SSH_S M S G_F A ILU R E 包回应。

第四阶段:

认证完成后,客户端向服务器提交会话请求。服务 器则进行等待,处理客户端的请求。在这个阶段,无论什么请求只要成功处理了,服务器都向客户端回应 SSH_S M S G_S U CC E SS包;否则回应

SSH_S M S G_F A ILU R E 包,这表示或者是服务器处理请求失败,或者是不能识别请求。会话请求分为这样几类:申请对数据传送进行压缩、申请伪终端、启动X11、TCP/I P 端口转发、启动认证代理、运行 she ll、执行命令。到此为止,前面所有的报文都要求 I P 的服务类型(T O S)使用选项I PT O S_THR OUG HP U T。

第五阶段:

会话申请成功后,连接进入交互会话模式。在这个模式下,数据在两个方向上双向传送。此时,要求 I P 的服务类型(T O S)使用 I PT O S_LOWDEL A Y 选项。当服务器告知客户端自己的退出状态时,交互会话模式结束。

(注意:进入交互会话模式后,加密被关闭。在客户端向服务器发送新的会话密钥后,加密重新开始。用什么方法加密由客户端决定。)

第二部分:数据包格式和加密类型

二进制数据包协议:

包 = 包长域(4字节:u_int32_t) +填充垫(1-7字节)

+ 包类型域(1字节:u_ch a r) + 数据域

+校验和域(4字节)

加密部分 =填充垫+ 包类型+ 数据 +校验和

包长 = 1(包类型) + 数据字节长度 + 4(校验和)

数据包压缩:

如果支持压缩,包类型域和数据域用 gz i p压缩算法进行压缩。压缩时在两个数据传送方向的任何一个上,包的压缩部分(类型域+数据域)被构造得象是它连在一起,形成一个连续的数据流。在两个数据传送方向上,压缩是独立进行的。

数据包加密:

现时支持的数据加密方法有这样几种:

SSH_C I PH E R_NONE 0 不进行加密

SSH_C I PH E R_IDE A 1 IDE A 加密法(C FB模式)

SSH_C I PH E R_DE S 2 DE S 加密法(C B C模式)

SSH_C I PH E R_3DE S 3 3DE S 加密法(C B C模式)

SSH_C I PH E R_ARC FOU R 5 Arc f our加密法)

SSH_C I PH E R_BLOWFI SH 6 Bl o wf ish 加密法

协议的所有具体实现都要求支持3DE S。

DE S 加密:

从会话密钥中取前8个字节,每个字只用高7位,忽略最低位,这样构成56位的密钥供加密使用。加密时使用C B C 模式,初使矢量被初始化为全零。

3DE S 加密:

3DE S 是 DE S 的变体,它三次独立地使用 C B C 模式的DE S 加密法,每一次的初始矢量都是独立的。

相关文档
最新文档