Ctrl+K

SSH客户端的实现1 加密通信的建立#

目的#

  • ssh是研发的必用工具，有必要了解其工作原理和学习其相关知识。

  • 主要任务是调通总体流程，实现一个简单的客户端。

  • 细节上肯定问题，且不通用。暂且不去纠结。

环境#

  • 测试服务器ssh版本是SSH-2.0-OpenSSH_8.2p1 Ubuntu-4。

  • key交换算法用diffie-hellman-group-exchange-sha256

  • 加密算法用aes256-ctr

  • mac算法用hmac-sha2-256

  • 公钥算法用ssh-rsa

  • 用python3编码

  • 加密库用 https://cryptography.io/en/latest/

  • gui库用 https://github.com/hoffstadt/DearPyGui

介绍#

The Secure Shell (SSH) Protocol Architecture

https://www.rfc-editor.org/rfc/rfc4251

rfc4251为ssh协议的整体描述 ssh协议分为三部分

  • 传输协议 Transport Layer Protocol 提供传输的保密性、完整性、压缩。一般运行在tcp/ip之上。

  • 鉴权协议 User Authentication Protocol 对连上ssh服务的客户端进行鉴权。运行在传输协议之上。

  • 连接协议 Connection Protocol 把加密通道分为多个逻辑通道。运行在鉴权协议之上。

整体架构#

host key#

服务端必须有一个host key。用与在key交换的过程中确保client连上的是正确的server。 而client必须事先知道这个key。

两种信任模式：

  1. client维护一套host和key的对应 这种方法不需要第三方介入。但需要花资源维护数据。

  2. host key由CA验证 client只需记住CA的root key，通过CA来验证server的host key。

第二种解决了维护问题，

扩展性#

技术、协议、算法是会不断进化，目前rfc只规定最简的架构和算法，必须保证可扩展性。

策略#

ssh协议允许下列事项的自由协商：加密、完整性、key交换、压缩、public key算法和各种格式。

下列事项需要在实现时进行确定：

  • 两个方向的加密、完整性和压缩算法

  • public key算法和key交换方法。

  • 认证算法

  • 用户在连接协议之上可进行的操作。

安全属性#

ssh协议的一个主要目的就是让网络更安全。

  • 所用加密、完整性、public key算法必须是知名、经过考验的算法。

  • 对于使用了较安全的key长度的算法，有能力抵御几十年的攻击。

  • 所有算法都是可协商的。如果某个算法爆出问题，可以轻易替换为其他算法，而不用改基础协议。

本地化和字符集支持#

很难统一。应尽量指定字符集。一般需支持utf8。

ssh协议里的数据类型#

byte#

8位数据。byte[n]表示n个字节。

boolean#

一个byte。0为false，1为true。

uint32#

32位无符号整数。按network byte order即大端存，即0x29b7f4aa存为29 b7 f4 aa。

uint64#

64位无符号整数。

string#

任意长度字符串。开头用一个uint32表示后续字符串的长度n。接着是n个byte。 可按需用ascii或utf8等编码

mpint#

用2的补码形式表示的多精度整数。 整个数据是一个string，即开头是一个uint32指定后续数据长度。 如果是负数，数据部分的第一位必须是1。（见下面的-1234） 如果一个整数的第一位是1，那么需要在开头加个0，来和负数区分。（见下面的80）

value (hex)        representation (hex)
-----------        --------------------
0                  00 00 00 00
9a378f9b2e332a7    00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80                 00 00 00 02 00 80
-1234              00 00 00 02 ed cc
-deadbeef          00 00 00 05 ff 21 52 41 11

bin(0xedcc) 0b1110 1101 1100 1100 取反 0b0001 0010 0011 0011 +1 0b0001 0010 0011 0100 hex为1234。加上负号即为-0x1234。

name-list#

用,号隔开的字符串列表。每个字符串长度必须大于0，不能包含,号。 只能包含ascii。第一个uint32为后续总长度。

value                      representation (hex)
-----                      --------------------
(), the empty name-list    00 00 00 00
("zlib")                   00 00 00 04 7a 6c 69 62
("zlib,none")              00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65

消息编号#

https://www.rfc-editor.org/rfc/rfc4250#section-4.1.1

传输层协议
1-19 传输层常用(比如disconnect, ignore, debug等)
20-29 算法协商
30-49 key交换方法

用户鉴权协议
50-59 通用
60-79 特定

连接协议
80-89 通用
90-127 通道相关

为client保留
128-191

本地扩展
192-255

Binary Packet Protocol ssh的数据包格式#

https://www.rfc-editor.org/rfc/rfc4253#section-6

uint32 数据包总长度
byte 填充长度
byte[n1] payload。 n1 = 数据包总长度 - 填充长度 - 1
byte[n2] 随机填充数据。 n2 = 填充长度
byte[m] mac(Message Authentication Code)。

最大长度

  • 必须能处理不压缩的长度为32768的payload。

压缩

  • 如果协商了启用压缩。将会对payload进行压缩。

加密

  • 加密算法和密钥会在密钥交换过程中协商好。 如果启用加密。包的总长度、填充长度、payload、填充数据都会进行加密。

完整性

  • 每次对数据包算一个mac(Message Authentication Code)来保证完整性。

Public Key Algorithms 公钥算法#

暂且忽略

Diffie-Hellman key交换算法#

https://www.rfc-editor.org/rfc/rfc4419
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
https://en.wikipedia.org/wiki/Discrete_logarithm
https://zh.wikipedia.org/wiki/%E7%A6%BB%E6%95%A3%E5%AF%B9%E6%95%B0

  • 用来在没有一个安全通道的情况下，在两端生成一个公用的secret。

  • 必须两端共同参与生成，无法由单独一端生成。

  • secret只有这两端知道，即使交换过程被监听也很难被破解。

  • 后续两端在这个secret的基础上加密通信数据。

离散对数问题#

对于 e = g^x mod p p是一个很大的质数，比如1024bit。 从g、x、p可以快速算出e。 但从已知的e、g、p，很难求得x。

  • Diffie-Hellman key交换算法的安全性就是基于这个难题。 很多密码学的组件都是基于离散对数问题。

  • key交换算法最后产出一个公共的密钥K和一个hash值H。 之后加密和授权等会依赖这两个值。

变量定义#

p 大质数
g generator
min client可接受的最小的p的位数
n client希望的p的位数
max client可接受的最大的p的位数
V_S server的版本信息
V_C client的版本信息
K_S server的public host key数据
I_C client的KEXINIT消息
I_S server的KEXINIT消息

流程#

1.client发key交换请求#

byte SSH_MSG_KEY_DH_GEX_REQUEST
uint32  min
uint32  n
uint32  max

比如min、n、max我都取2048。

2. server找最匹配的group#

server需要存一批精心挑选的通用的安全质数(safe primes)p和各自对应的generator g。

见 https://www.rfc-editor.org/rfc/rfc3526

我们client传了2048，那么会找到2048bit的group。

https://www.rfc-editor.org/rfc/rfc3526

This group is assigned id 14.

   This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }

   Its hexadecimal value is:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AACAA68 FFFFFFFF FFFFFFFF

   The generator is: 2.

那么p值就是那一大串hex。g就是2。

server发确定的p和g

byte    SSH_MSG_KEX_DH_GEX_GROUP
mpint   p
mpint   g

3. client计算e#

client生成一个随机数x。1 < x < (p-1)/2。

e = g^x mod p 比如 e = pow(2, 666666666666666666, p) pow必须加mod参数。也必须加mod限定，才能快速算出可行的结果。

client发

byte    SSH_MSG_KEX_DH_GEX_INIT
mpint   e

这里想一下，client发数据时，e、g、p都是在网络上可见的，是不安全的，但是因为离散对数难题，x可以认为是无法破解的。

4. server#

server生成一个随机数y。1 < y < (p-1)/2。 f = g^y mod p

K = e^y mod p K即为双方共同生成的key。这里是基于取模运算的性质的，后续会说明。

H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K) 用私钥对H签名得到s

我们用的是diffie-hellman-group-exchange-sha256。 所以hash函数就是sha256

hash内容的格式

string  V_C, the client's version string (CR and NL excluded)
string  V_S, the server's version string (CR and NL excluded)
string  I_C, the payload of the client's SSH_MSG_KEXINIT
string  I_S, the payload of the server's SSH_MSG_KEXINIT
string  K_S, the host key
uint32  min, minimal size in bits of an acceptable group
uint32  n, preferred size in bits of the group the server will send
uint32  max, maximal size in bits of an acceptable group
mpint   p, safe prime
mpint   g, generator for subgroup
mpint   e, exchange value sent by the client
mpint   f, exchange value sent by the server
mpint   K, the shared secret

server发送

byte    SSH_MSG_KEX_DH_GEX_REPLY
string  K_S
mpint   f
string  s

5. client#

client校验K_S，确保是server合法的host key。也可以不校验，但是有风险。

解析server的host key https://www.rfc-editor.org/rfc/rfc4253#section-6.6

K = f^x mod p

H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K) 验证签名s

到此两端得到了相同的key K。

为什么两边会得到同一个key#

  • x是client的随机数，y是server的随机数。

  • 基于取模运算的性质： server算得的 K = (g^x mod p)^y mod p = g^(xy) mod p client算得的 K = (g^y mod p)^x mod p = g^(yx) mod p

所以两端利用离散对数难题把包含x和y的数据发给对方，即使中途被窃听也解不出x和y。 两端并不用解出对方的随机数，而是利用取模运算的性质，非常巧妙地达成了一致。

数据包的加密和完整性#

  • key交换完成后。通信数据都要加密，并且验证完整性。

  • 我们用aes256-ctr加密，32字节的key，加密block长度为16字节，模式为ctr。
    按文档，必须把数据填充成长度为block长度和8之间大的那个数的倍数。这里就定为16字节的倍数。
    https://www.rfc-editor.org/rfc/rfc4253#section-6

  • 先正常拼数据

uint32 数据包总长度
byte 填充长度
byte[n1] payload。 n1 = 数据包总长度 - 填充长度 - 1
byte[n2] 随机填充数据。 n2 = 填充长度

  • 得到未加密的数据包，包含padding。总长度为16的倍数。

  • 再用mac key对[消息sn+未加密的数据包]算一个mac，附在数据包后面。 每发一个包，sn+1。从0开始，达到2^32归零。 mac = MAC(mac_key, sn || 未加密的数据包) sn为uint32

  • mac_key用公共密钥算。跟加密key相似。 https://www.rfc-editor.org/rfc/rfc4253#section-7.2 Integrity key client to server: HASH(K || H || "E" || session_id) mac算法选择hmac-sha2-256，生成一个32字节的hash。

  • session_id为第一次算得的H值。即使后续重新交换key，也不变。

  • 再用加密key对数据包加密。

  • 最后发给server的数据为[加密后的数据块+mac]。

  • 解析server数据时以反方向操作即可。

数据包的边界问题#

  • tcp可能出现一个ssh数据包分批到达socket接口，或者socket接收时收到不止一个完整的包。 需要定包边界。

  • 不加密时，前4字节一定是包的长度，没有问题。

  • 加密后其实也没问题。 aes的ctr模式是分块独立加密，这样每次解析新数据包时可以先读16字节解密，作为头。
    头的前4字节是包的长度，这样包的边界实际也是定好的。
    每个新包先读16字节，解密。再读剩下的包长度。最后读mac数据即可(mac长度是根据算法定死的32)。

总体流程#

1. 交换协议版本#

https://www.rfc-editor.org/rfc/rfc4253#section-4.2 两端互发包含协议版本等信息的字符串

server端的版本是 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4\r\n

client端的版本是 SSH-2.0-WTFFFFFF\r\n 类似版本

2. 算法协商#

https://www.rfc-editor.org/rfc/rfc4253#section-7.1 两端互发支持的算法

byte         SSH_MSG_KEXINIT
byte[16]     cookie (random bytes)
name-list    kex_algorithms
name-list    server_host_key_algorithms
name-list    encryption_algorithms_client_to_server
name-list    encryption_algorithms_server_to_client
name-list    mac_algorithms_client_to_server
name-list    mac_algorithms_server_to_client
name-list    compression_algorithms_client_to_server
name-list    compression_algorithms_server_to_client
name-list    languages_client_to_server
name-list    languages_server_to_client
boolean      first_kex_packet_follows
uint32       0 (reserved for future extension)

kex_algorithms 列出key交换算法

server_host_key_algorithms host key算法

encryption_algorithms 加密算法

mac_algorithms mac算法

compression_algorithms 压缩算法

都是左边优先，如果两边一个都匹配不到。断开连接。 因为算法是会进化的，所以新的server不一定支持老的客户端。算法匹配不了，server就会主动断开连接。

3. Diffie-Hellman Group Exchange 生成密钥#

见上述算法流程。

结束后两端互发一个 SSH_MSG_NEWKEYS 表示key已经生成，以后都得用新的key和算法进行加密交互。

key不是直接用dh算法生成的K。而是要算hash值的。

https://www.rfc-editor.org/rfc/rfc4253#section-7.2

Encryption key client to server: HASH(K || H || "C" || session_id)

这一条就是client发数据给server要用的加密key，用sha256算出最终的32字节hash值。

4. client请求服务#

https://www.rfc-editor.org/rfc/rfc4253#section-10

key交换完毕，client请求auth服务。

https://www.rfc-editor.org/rfc/rfc4252

client发

byte      SSH_MSG_SERVICE_REQUEST
string    "ssh-userauth"

4.1 aes加密#

  • 根据 https://www.rfc-editor.org/rfc/rfc4253#section-7.2 必须算出自己方向的加密iv、加密key和mac key。

  • 选择aes256-ctr。aes256需要32字节的key，aes128需要16字节的key。

  • 因为密钥选择使用sha256计算，有32字节。所以如果加密算法选的aes128，就得传密钥的前16字节。

  • 这种输入输出长度都得搞清楚，否则server会直接断开。

  • 可自己起ssd服务sshd -ddd来debug。一般加解密出问题会报bad packet length。mac出问题会报 mac corrupted。

5. server接受服务请求#

server端收到client的数据，进行解密和mac验证。通过后发：

byte      SSH_MSG_SERVICE_ACCEPT
string    service name

client同样进行解密和mac验证。 都通过后两端即建立起了基本的加密通信通道。

参考#

https://www.rfc-editor.org/rfc/rfc4250
https://www.rfc-editor.org/rfc/rfc4251
https://www.rfc-editor.org/rfc/rfc4252
https://www.rfc-editor.org/rfc/rfc4253
https://www.rfc-editor.org/rfc/rfc4254
https://www.rfc-editor.org/rfc/rfc3526
https://www.rfc-editor.org/rfc/rfc4419
https://www.openssh.com/
https://www.paramiko.org/
https://cryptography.io/en/latest

On this page