python - paramiko ssh 客户端在主机 key 签名不匹配中失败

Question

我们有一个 SSH 服务器实现，我们正在使用 Paramiko 客户端来测试它在 diffie-hellman-group-exchange-shaX 的主机 key 签名不匹配中始终失败。我已经找出了签名不匹配的原因，但无法理解哪个端服务器或客户端做错了。以下是不匹配的原因

1.Client向Server发送“min || n || max”。

2.Server找到与客户端请求最匹配的组，并发送
“p || g”给客户。其中 p 是大素数，g 是生成器
现在问题发生在服务器发送大小大于一的生成器的情况下，该生成器以字节数组表示，前面有零加上它前面的长度为(大数字表示)
00 00 00 04 00 00 00 02在哪里 04是生成器长度，02是它的值(value)。用于主机 key 签名匹配的 H 将完整的字节缓冲区用于大数字进行散列。 H 表示为
H = hash(V_C
|| V_S || I_C || I_S || K_S || min || n || max || p || g || e ||
f || K)
现在，当 paramiko 存储生成器时，它会删除前面的零并且不存储长度。
它将 g 转换回字节并使用 len(g) 预先挂起字节压缩 g 的长度以进行散列
使用以下例程。

def add_string(self, s):
    """                                                                                                                                                                                                                                  
    Add a string to the stream.                                                                                                                                                                                                          

    :param str s: string to add                                                                                                                                                                                                          
    """
    s = asbytes(s)
    self.add_size(len(s))
    self.packet.write(s)

这只是一个字节，所以我们本质上为 g 字节缓冲区散列的内容如下 00 00 00 01 02其中 01 是字符串长度，02 是与服务器 g 缓冲区不同的值，因此签名不匹配

所以我的问题是哪一边不正确地代表大数字的字节缓冲区？

Answer 1

根据 RFC4251:

Blockquote

  mpint
  Represents multiple precision integers in two's complement format,
  stored as a string, 8 bits per byte, MSB first.  Negative numbers
  have the value 1 as the most significant bit of the first byte of
  the data partition.  If the most significant bit would be set for
  a positive number, the number MUST be preceded by a zero byte.
  Unnecessary leading bytes with the value 0 or 255 MUST NOT be
  included.  The value zero MUST be stored as a string with zero
  bytes of data.
  eg: 80(hex)                 00 00 00 02 00 80

因此，服务器所做的事情是错误的，而 paramiko 在删除前面的填充零方面是正确的。