第一篇文章就献给我比较喜欢的安全方面的协议吧。

  今天的工作是验证了我们新设备的SSH模块功能，说实话，对于这类安全的模块我还是比较感兴趣的，所以我希望我可以从协议的封装字段的层面去了解这个协议完整的执行过程，不过我也知道一口吃个胖子不太现实，所以我就结合自己对于这类加密认证的协议来给未来的我聊聊现在这个“菜鸟自我”的理解吧。

  众所周知，一个协议的产生无非几种情况，要么是根据市场的需求专门研究创造出来的，来完成特定的要求，我们想为每台硬邦邦的设备标个身份的标签，就有一帮人创出了一个叫MAC的东西，他们之间想聊聊天，就又有人弄出了一个叫IP的东西，在一张大网上向周围的邻居和远方的朋友说，嘿，我的名字叫10.10.10.10，那个叫20.20.20.20的你是哪位啊？好吧，arp出来了，诸如此类的东西；另外一种就是进化来的，就是已经有了一个祖先的存在，只不过社会发展了，这个东西已经不足以满足人们目前的需求了，这大概就是进化论吧，所以我们要改进，ftp不安全了，我们弄个sftp，S嘛，secure而已，说白了就是安全的ftp，包括那些一弄就是一大排的版本，rip v1、v2、v3，ipv4、ipv6，好吧，都是一个家族的。那么这个SSH又是个什么东西？

  我想大家应该都知道我们管理设备最直接的方法就是拿一根线插入设备的console口中，而人们路远就研究了一个telnet来远程登录并管理设备，但是我们知道telnet的所有认证信息都是明文形式，这样就很容易遭受到网络中不法分子的窥视、修改、盗取。所以我们就想能安全的telnet到远端的设备，就产生了这个SSH。

  SSH（Secure Shell ），安全外壳，由IETF制定的，建立在应用层和传输层基础上的安全协议，专为远程登录会话和其他网络服务提供安全保证的一个协议，采用的模式为C/S的模式，也就是客户端.服务器模式，我将它真正想象成一个外壳，它将我们的登录请求，身份验证等需要保护的信息包裹起来，放在事先双方协商好的一个通道上传输，到达对端后，在通过一层层的判断，一层层的剥掉，直到露出其中的真正信息（当然真正的过程不可能这么简单）。

  SSH协议我自己比较看重的就在于它大众化的加密认证理念，简单明了：明文直接的认证不安全？好吧，我加上口令，设个密码来认证；口令不安全？我将这个口令加密；然后就是传统的公/私密钥对的分发问题，来来回回的认证过程，这里涉及到如何加密的地方我就不说了，因为这不是我今天工作中遇到的主要问题。

  在一开始我就说了，我希望能从整个协议的交互的数据报文封装结构去理解这个协议，这也是我在半天的工作中所观察的地方，SSH协议的工作过程可以总结为以下几个步骤：

  • 连接建立
  • 版本协商
  • 算法协商
  • 密钥交换
  • 用户认证
  • 服务请求
  • 数据传输和连接关闭

第一步：连接建立 SSH工作在TCP/IP基础上，所以这里连接的建立就需要最基本的TCP的连接建立，后面就是各种的三次握手之类的可爱的过程，当然，这其中的TCP的目标端口当然要用默认的22号端口，哦，神，各种syn，syn+1,syn+ack,syn+ack+1，这个过程里面的报文封装我又不熟悉了，要去复习了，ORZ。。

第二步：版本协商 协商SSH的版本，利用SSH v1、v1.5、还是v2，这里的版本当然也是封装在交互的SSH报文中，C、S互发，告诉对面自己能支持的版本有哪些，最后两个人商量好就用我们都支持的并且最大的那个，好吧，这一点我很赞同，大的就是新的，新的就是好的。

第三步：算法协商 一开始我的理解是这些报文都是有专门的交互报文的，比如在第二步的版本协商时，C、S相互发送的SSH报文里面关于SSH的内容只包含版本信息，不过再看了抓到的报文后，我发现自己错了，原来这几个步骤之间在报文的封装上都是会有交叉的，哦天啊，我在这里给自己减轻点压力吧，既然是写给以后的自己看的，写错的内容就在以后的BLOG中纠正并给自己道歉吧。言归正传，算法协商，C、S都向对方说自己支持的加密算法有哪些，然后2个人选出都支持来进行加密运算，我印象中今天抓的报文中封装的有3种，貌似包括：产生会话密钥的密钥交换算法，包括diffie-hellman-group-exchange-sha1、diffie-hellman-group1-sha1和diffie-hellman-group14-sha1算法等；对数据信息的加密算法。包括3des-cbc、aes-128-cbc和des-cbc等加密算法；用于数字签名和认证的公钥算法，RSA和DSA；数据完整性验证的hmac-md5、hmac-md5-96、hmac-sha1和hmac-sha1-96等。

第四步：密钥交换 呃，顾名思义，就是交换密钥，通过协商出来的密钥交换算法，在通信双方安全动态地生成和交互数据的加解密密钥。

第五步：用户认证 重点来了，前面的种种铺垫啊，伏笔啊都为了现在做准备了，由于自己的总结能力不好，所以这里就不好意思一下，用H3C的SSH技术白皮书的一点内容来给自己说明一下认证过程吧：

(1)        客户端向服务器端发送认证请求报文，其中携带的认证方式为“none”。

(2)        服务器收到none方式认证请求，回复认证挑战报文，其中携带服务器支持、且需要该用户完成的认证方式列表。

(3)        客户端从服务器发送给自己的认证方式列表中选择某种认证方式，向服务器发起认证请求，认证请求中包含用户名、认证方法、与该认证方法相关的内容：

l              密码认证方式中，内容为用户的密码；

l              公钥认证方式中，内容为用户本地密钥对的公钥部分（公钥验证阶段）或者数字签名（数字签名验证阶段）。

(4)        服务器接收到客户端的认证请求，验证客户端的认证信息：

l              密码认证方式：服务器将客户端发送的用户名和密码信息，与设备上或者远程认证服务器上保存的用户名和密码进行比较，从而判断认证成功或失败。

l              公钥认证方式：服务器对公钥进行合法性检查，如果不合法，则认证失败；否则，服务器利用数字签名对客户端进行认证，从而判断认证成功或失败。

(5)        服务器根据本端上该用户的配置，以及用户认证的完成情况，决定是否需要客户端继续认证，分为以下几种情况：

l              如果该种认证方式认证成功，且该用户不需要继续完成其他认证，则服务器回复认证成功消息，认证过程顺利完成。

l              如果该种认证方式认证成功，但该用户还需要继续完成其他认证，则回复认证失败消息，继续向客户端发出认证挑战，在报文中携带服务器需要客户端继续完成的认证方式列表；

l              如果该种认证方式认证失败，用户的认证次数尚未到达认证次数的最大值，服务器继续向客户端发送认证挑战；

l              如果该种认证方式认证失败，且用户的认证次数达到认证次数的最大值，用户认证失败，服务器断开和客户端之间的连接。

好吧，上面都是基本的认证过程，但最失败的是我没有带回家今天在公司抓取的报文，所以写到这里我很惭愧的对自己说，我准备的不够充分，毕竟今天写这些也是一时冲动造成的。

  今天在公司验证的时候发现整个SSH协商卡在ssh server向客户端发送了加密响应报文，而客户端则没有回应，所以连接断开，我会在明天晚上带回来报文并继续研究SSH协议。

  小子，我希望你不要研究到一半就扔到一边了，写了这么多都是堆自己的承诺，什么有其他工作，什么有IPV6要看，都是放弃这个SSH研究的借口，明天晚上吃饭回来一定要继续完成这个研究，然后再周4的时候，老老实实写下当天IPV6的技术交流心得！

  天晚了，就到这里吧，就当复习了，明天吃饱喝足回来，继续看SSH哦！