SSH连接抓包分析

一、概念

SSH ： Secure Shell
是一项工作在应用层的协议，采用TCP传输，默认端口22，用于远程控制终端

二、连接流程

1、TCP三次握手建立连接
2、SSH协议版本交换
3、算法协商
4、ECDH密钥交换
5、产生会话密钥 —— 加密通道正式启用
6、用户身份认证（密码登录/公钥认证登录）
7、远程控制

三、抓包分析

现通过抓包来将连接流程具体呈现

1、实验背景

Win主机尝试连接一台已经开启SSH服务端功能的Linux主机

2、流量分析

下面着重对会话密钥协商部分的包进行详细拆解

• Key Exchange Init：交流两端所支持的加密方式
  

• Elliptic Curve Diffie-Hellman Key Exchange(椭圆曲线迪菲-赫尔曼算法密钥交换）
  客户端：
  
  服务器：
  

四、身份认证方式

    SSH的理念是先保保密性，再进行身份认证。通过上面的抓包可知一旦产生New Key，会话就完全加密，而直到New Key产生，用户此时都还未输入远程主机的账户密码。因此还没结束，在完成建立加密通道后，服务器还需要对客户端用户身份进行验证。

SSH常用有2中身份验证方式：
1、基于口令验证
    客户端通过在协商会话密钥时接收到的服务端主机公钥，加密自己的口令发给服务端；服务端用自己的私钥解开口令进行比对。这种方式常用于登录远程主机进行管理。

2、基于公钥认证
Github就可以看到这个典型的例子。

    客户端自己先在本地生成一个自己主机用户钥匙对，并在服务端上预先存放好钥匙对的公钥，自己保管好私钥。之后的流程如下图

注意：别忘了这些认证都进行在有会话密钥保护的情况下。

总结于思考：

•     基于口令的验证方式存在中间人攻击的风险，而SSH将这种风险交给了用户去承担，当客户端初次连接一台未知主机时，SSH往往会发出提示，需要用户自行去验证服务器公钥指纹的真实性，最好的办法就是使用另外一条连接去获取真实主机的公钥指纹。
  
      而实际情况往往是用户不对公钥指纹进行审视，选择无视风险，直接输入yes，这也给了中间人可乘之机。云服务器厂商更应该注意到这一点，其有必要在用户购买的产品详情页面为用户提供最初始的ssh主机公钥指纹，这才是安全且负责的做法。
  

•     相比口令验证，公钥验证方式可以避免每次输入口令的繁琐操作，这也是为什么程序员在初次安装git后只要配置好一次ssh公钥，就可以轻松上传代码至中央仓库，而无需手动输入口令。此外，这种验证方式也降低了被中间人攻击的可能性。

上述部分引自博客：https://www.cnblogs.com/diffx/p/9553587.html
这篇博客写得很好，读者可以阅读一下，加深理解。

五、SSH常用加密算法

密码学算法
│
├── 对称加密（加密通信内容）
│ ├── AES
│ └── DES
│
├── 非对称密码（公钥体系）
│ ├── 基于大整数
│ │ └── RSA
│ │
│ └── 基于椭圆曲线（EC）
│ ├── ECDH ← 密钥交换
│ ├── ECDSA ← 数字签名
│ └── EdDSA ← 数字签名（Ed25519）

    在上面的抓包分析中可以发现会话密钥协商出来后才开始完全加密通信，而后续的通信都使用这个会话密钥进行对称加密，通常是AES。而服务器主机ED25519钥匙对仅仅用于身份的验证和签名。这样做是有道理的，主机密钥极其重要，如果泄露可能造成整台主机流量完全受到威胁，因此尽量不使用，频繁的通话依然需要靠会话密钥。即便一条通信链路的会话密钥被泄露，也不会对整个主机的网络构成威胁。这还仅仅是一个主要的因素。

有人会问：既然用户已经确认服务器发来的主机公钥了，为什么不直接用这个公钥来进行加密？

其实如果理解了上面一段话，这一个问题也就解决了。此外还应该清楚，非对称加密算法往往会比对称加密造成更多资源开销。