昨天写的SSH的基本交互过程中并没有按照原定的计划通过分析SSH的交互报文数据封装来完成对整体SSH报文的分析，所以今天带回来了SSH的报文，由于BUG的问题，目前手边仅仅有几种SSH的报文，并不能全部都拿来分析，所以这里仅就手边抓取到的SSH报文进行分析吧。

  上篇提到过，SSH的数据交互都需要建立在一条安全的通道中，这里的通道就是C、S双方协商的TCP通道。

  • 在进行了初步的TCP基本握手的前提下，我们可以看到client和server会首先向对方发送如下SSH报文：
 
此处的SSH报文在TCP封装之上封装SSH Protrol里仅用来宣告SSH版本为2.0，并且表明client本身为CRT客户端。
同理，server向client宣告的server protrol中包含了SSH的版本为2.0及作为server的设备为公司的设备。
  • 在完成了对SSH版本的协商后，client和server会相互发送的SSH报文的类型就变成了协商好的版本：SSHv2。描述为：client/server：key exchange init
 
 
 
这两个报文中在SSH protrol中主要封装的信息为交互的key信息：
 
 

在key exchange init中我们可以看到client和server相互告知对方自己所支持的各种算法，如上图中的公钥交换算法、加密算法、完整性验证的算法等。以上截图仅为client向server发送的key exchange init报文，同样的server也会向client发送。

  • C、S相互宣告对方自己所支持的各种算法后，双方就完成了协商，接下来client向客户端发送Diffie-Hellman Key Exchange init报文：
     

我理解为这是client在向server交互密钥加密算法的结果，并且在后续server也给了reply：

 
  • 接下来进行client和server相互交互key，这里我存在疑问，就是如下图的new keys报文交互的具体是什么，由于这次SSH的认证过程实际上以失败告终，所以我不能给自己下定论，需要在后面的学习中解开这个疑问，至今没找到完整的SSH认证的过程的全部报文：
  • 在key exchange后我抓到的报文就到了该次失败学习过程的结尾：server连续6次的Encrypted response packet报文，而client在此期间并没有给出回应：
     

此报文我并没有理解其用途，哎，这里就是终结我的地方了，我开始认为这里是上篇交互过程中所提到的server给client的挑战报文，而client没有完成挑战，可能造成的原因是设备BUG问题造成数据报文封装错误，client无法识别，不过具体的问题还有待我去继续研究，在new key到这个报文中有个比较奇怪的TCP报文：

 
 、
该TCP报文中包含了SSH封装，但是仅仅只有一个版本号而已，难道这个就是client向server发送的认证方式为none的认证请求报文吗？可是怎么看都不像啊！！
 
 
整体的SSH报文交互过程截止到密钥算法的交互这里，后面的过程还需要我去找资料，进行测试，我相信我能找到问题的关键并且完全理解SSH。
 
好啦！小子，12点了，明天的IPV6内容还没去预习，待抽出时间来完成SSH的内容，我再来给你讲解吧，这些疑问，就留待以后吧！相信时间不会很长哦。