SSH2.0编程 ssh协议过程实现（转）

　　SSh协议：

　　全称为Secure Shell，即很安全的shell，主要目的是用来取代传统的telnet和r系列命令（rlogin，rsh，rexec等）远程登录和远程执行命令的工具，实现远程登录和远程执行命令加密，防止由于网络监听而出现的密码泄露，从而对系统构成威胁。（telnet协议采用明文传送密码，数据传送过程中也不加密）

　　ssh协议目前有ssh1 和ssh2，其实现在我们主要使用的也是openssh。ssh不仅在登录过程中对密码进行加密传送，而且在登录后执行的命令的数据也进行加密，这样即使别人在网络上监听并截获了你的数据包，他也看不到其中的内容。

之前为了自己做一套SSH，先自己实现了一套telnet。但经过这么多天的苦逼，发现以前的工作都是徒劳。ssh的协议很繁杂，核心的内容在于密码算法，而且自己很难在网上找到周全的细节讲解与详细的实现，只有靠自己刷RFC和问大神还有就是靠强X我的服务器艰难地完成。

现计算了下时间，自己做SSH耗费了进两个月的时间，虽然期间也夹着其他的繁杂事物，但自己在这方面确是是耗费了非常大的精力。因为这方面详细资料的匮乏，自己以前也几乎没有接触过密码学方面的东西，很多只有靠自己摸索，所以我得经常拿我自己的服务器来做黑盒测试，我现在服务器上的ss服务器日志全是一些非法连接的记录（—_—|||）。早知当初就不那么作死非要自己实现他的加密算法和过程，用openssl就很快搞定了。但我还是觉得这次做SSH的精力是我受益匪浅，不仅熟悉了各种加密，并且能靠自己实现并熟练应用了。可能这些对自己帮助不大，但至少和信安的小伙伴也有点吹牛的谈资了~

这篇文章希望能帮助到想了解ssh2.0协议或是亲手实现ssh协议的小伙伴。

首先对数据包的格式进行说明：

数据包由包长度（Packet Length）、填充长读（Padding Length）、信息代码（Msg code）、信息内容与填充值（Padding String） 这5部分组成。信息内容中的一些字符串以4字节长度+该长度数量的字符组成，数值按照网络序排列，例如：abc: 00 00 00 03 (char)a (char)b (char)c 。另外有一种大整数的情况，负数和字符串的表示方式一样，正数需要前导0，例如 4b64： 00 00 00 03 00 4b 64 。

ssh头的结构体:

就拿通过ssh远程控制的一个完整个过程来讲，ssh的过程可分为以下3部分：

一、版本协商

二、算法协商与密钥交换

三、加密通信（可能含有2、3部分）

这其中第二部分是ssh最为核心的过程，该过程决定了以后通信所要使用的密钥，下面按顺序对每个部分对比着数据包进行详细的讲解并给出实现的过程。

一、版本协商：

在建立连接后，客户端与服务器分别向对方发送自己ssh的版本信息（这里的数据格式不同于其他包，只有一行版本号），以\r\n结束。版本的格式如下：

SSH-ssh协议版本-详细版本\r\n （几乎只有ssh协议版本之前的信息有效）

比如我linux上的就是：SSH-2.0-OpenSSH_5.3\r\n

Putty的是： SSH-2.0-PuTTY_Release_0.63\r\n





一般来说，在建立连接后，是先由服务器发版本号过来，单线程处理版本协商的朋友需要注意下。

在双方收到对方发来的版本号后，会根据两者之中最小的版本来进行接下来的通讯。

二、算法协商与秘钥交换：

这部分的内容将会占该文章总篇幅的一半以上。

首先给大家看下整个过程的数据包大概：



整个部分是从第6条开始到第15条结束，除去中间的非协议部分，总共有7条数据包。看起来只有这么几条数据包，但其中包含了非常多的过程与隐秘的信息。

1、算法协商：

位第6、9数据，分别为双发向对法发送的自己在不同密码需求上支持的算法。

该数据包的格式:





按顺序分别是：

cookie(随机的值，16byte)

kex_algorithms（秘钥租交换算法）

server_host_key_algorithms（服务器主机秘钥，正常情况用处不大，甚至可以不用）

encryption_algorithms_client_to_server（两端通信使用的加密算法）

encryption_algorithms_server_to_client

mac_algorithms_client_to_server（数据校验用的hash算法）

mac_algorithms_server_to_client

compression_algorithms_client_to_server（压缩算法）

compression_algorithms_server_to_client

languages_client_to_server

languages_server_to_client

first_kex_packet_follows

0（4byte整数，扩展用的）

每个算法类型可能会有多个不同的算法，这些算法之间使用逗号隔开。

现在双方知道对方支持的算法，但是应该怎样决定每个类型实际所使用的算法呢？

每个算法类型列表的第一个算法必须是首选的算法，服务器应以客户端的算法优先级作为考虑，就拿交换算法举例：

现在服务器有三个算法dh1,dh2,dh3

客户端有两个算法dh3,dh2

那么服务器的首选算法是dh1，而客户端是dh3，客户端此时知道服务器有dh3算法，因此客户端就确认使用dh3算法。服务器发现自己的首选算法与客户端不同，而自己拥有客户端的首选算法，因此服务器也确认使用dh3算法。

再看另一个情况

服务器：dh1,dh2,dh3

客户端：dh4,dh3,dh1

这时服务器没有客户端的首选算法，客户端会使用第二个算法dh3，此时服务器也支持第二个算法，双方将确定使用dh3算法。

如果服务器和客户端双方没有共同的算法，这次会话将会终止。

下面是代码实现和服务器之间的版本协商

用到的一些功能函数：

2、秘钥交换

在算法协商成功过后，双方便立马进行秘钥组的交换。ssh2.0版本所使用的秘钥组交换协议算法主要使用diffie-hellman-group-exchange-sha算法。

鉴于该部分内容特别多，我特意在另一篇单独的文章中予以详细介绍，再阅读下文前请先参考该文章：dh-gex-sha算法详解

我们数据包的第10到15条都是该部分的内容

1、dh key exchange init （C）





密钥交换初始化，由客户端先向服务器发送秘钥交换请求的数据包，告知开始秘钥交换。

2、dh key exchange reply （S)





服务器收到客户端发起交换的请求后，将自己用于dh算法的P、G发送给客户端，用于客户端生成dh公私钥。这里的P是一个大素数，而G是大于1的数，G不必过大，10位以内最后，因为按幂运算G能轻易生成特别大的数。

3、dh gex init (C)





客户端收到服务器发过来的P、G后，自己变成根据P、G生成并计算出自己的公钥e。这一步也只需要客户端将生成的e发送给服务器即可。

4、dhgex reply （S）





重要的来了，服务器收到了客户端发来的e后，便能计算出共享秘钥K，并根据现有信息计算出生成所需秘钥的H。

这个数据包里面含有如下信息：

KEX DH host key（K_S）：

主机公钥，一般为rsa公钥。完整的格式为：总长度+算法名长度+算法名+证书（n）长度+证书（n）+公钥长度+公钥。

DH server f ：

服务器的dh公钥值，客户端收到后便能用f计算出同样的共享秘钥K。

KEX DH H signature (签名后的H):

服务器用主机私钥对计算出的hash值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计算结果

5、new keys （C)





客户端收到服务器的信息后计算出K，并用同样的方式计算出H（服务器和客户端的H都是同一个值）。并使用服务器发过来的K_S验证服务器发过来的签名后的H，如果验证一致，则说明此次秘钥交换成功。客户端向服务器发送new key，标志秘钥交换过程的结束。如果此次秘钥交换是整个会话的第一次交换，则计算出的H也是整个会话的会话ID（session_id）。

秘钥基本信息在网络上的传输与交换，接下来就分别是服务器和客户端各自使用现有信息计算出以后加解密所要使用的秘钥。秘钥计算：

这里的加密秘钥指的是以后数据通信所用的秘钥，一般用aes算法。

计算方式：hash(K,H,单个字符,session_id);

单个字符指的是单个大写的ASCII字母，根据不同的加密秘钥选择不同的字符来计算。

字母	秘钥
'A'	客户端到服务器的初始IV（CBC）
'B'	服务器到客户端的初始IV
'C'	客户端到服务器的加密秘钥（对称秘钥）
'D'	服务器到客户端的加密秘钥
'E'	客户端到服务器的完整性秘钥(HMAC)
'F'	服务器到客户端的完整性秘钥

就以aes-cbc为例子，aes对称加解密所需要用到的值有初始IV与对称秘钥。这里的初始IV指的是cbc模式中加解密的初始向量，第二次加解密需要IV的值，以后的每次的加解密都要依赖于上一次加解密的数据。

三、加密通信

此时双方都拥有协商好的算法以及用于加解密的秘钥,现在开始所有传输的全部数据都要进行加密（包含总长度），并使用同样的。

在加密通信的过程中，双方允许重新发送KEX秘钥交换请求。这时整个秘钥交换过程的数据将会使用现有密钥加解密。在该次秘钥交换的过程中也会生成一个H值，但该H值不会影响到此次会话的session_id，session_id只是会话第一次秘钥交换生成的H值。在秘钥交换最后客户端发出new keys请求时。双方会放弃当前使用的秘钥，使用新协商的秘钥继续通信。

在远程数据的通信过程中，双方使用SSH_MSG_CHANNEL_DATA标志消息类型进行数据传输。

在秘钥交换完成后第一次对发送数据加密时，首先需要对AES向量进行初始化，即设置对应的IV。aes部分我使用的是CRYPTOPP的aes-cbc算法（在后文的有对该算法的封装）。

整个协议用到的主要加密算法的实现与封装：

ssh的实现就到此终于结束了，截图留念。





笔者在之初就想使用crypto++来帮助实现ssh过程的密码算法。而刚接触这东西完全搞不懂怎么用，什么编码器、生成器、过滤器、sink...这些概念根本就不懂，网上的使用文档直接就拿这一堆概念加上一堆组合出来的代码来实现一个加密算，没有什么密码学知识，想要快速掌握crypto++几乎是不可能的，当时研究了很久就只是会使用它的hash加密。而后自己硬着头皮实现了整个dh-gex，到后面aes后，发现自己能很自然得理解crypto++的用法了，便自己封装了crypto++的aes算法供使用。

总之都是好事，以后遇到其他的基于ssl的协议与应用就应能很轻松地理解与实现了。
http://www.cnblogs.com/wchrt/p/4550208.html