摘要

  • RFC 10042 定义三种 SSH 的 ML-KEM/ECDH 混合方法，并把两个临时共享秘密合成为 SSH 派生输入。
  • SSH_MSG_KEX_HYBRID_REPLY 可构成密钥交换的一部分证据，却不等于客户端已信任主机，也不等于用户获准进入。

最容易被误读的是服务器回复里的三个并列成分：主机公钥 K_S、复合的 S_REPLY，以及交换哈希上的签名。它们出现在同一个 SSH 消息中，并不意味着它们回答同一个问题。RFC 10042 让客户端用 SSH_MSG_KEX_HYBRID_INIT 发送 C_INIT，其中连接了 ML-KEM 公钥和经典公钥；服务器用 S_REPLY 返回 ML-KEM 密文与经典公钥的连接。两端据此得到后量子 K_PQ 与经典 K_CL，再按规定的定长字节编码哈希出 K。

这是一次密钥建立的精确机制。服务器在封装前必须确认 C_INIT 的长度符合协商方法；客户端在解封装前必须确认 S_REPLY 的长度。长度不对或解封装失败，客户端必须以密钥交换失败原因断开。每条连接还必须生成新的临时 ECDH 和 ML-KEM 密钥对，ML-KEM 密文的随机性不得复用。定长编码的目的之一，是避免秘密长度变化变成可观察的侧信道。

这些规则只能说明规范要求在何处失败或应当成功，不能让失败原因自动变成人或组织的结论。一次 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 不证明某个用户输错了凭据，也不证明某台主机不可信。相反，一条配置里出现混合方法名，也不证明有一次成功的混合会话。RFC 10042 注册的 mlkem768nistp256-sha256、mlkem1024nistp384-sha384 与 mlkem768x25519-sha256 是可协商机制的名称；它们仍需双方相容、实际选择、消息检查和密钥派生才能构成一次具体交换。

K_S 的边界尤其重要。SSH 传输层使用主机密钥签名来认证交换；RFC 4253 规定客户端计算交换哈希并验证签名。但同一规范也要求客户端确认 K_S 确实是目标服务器的主机密钥，例如通过证书或本地数据库。RFC 4251 进一步列出本地“主机名—密钥”关联与受信任 CA 两种模式，并承认首次不检查关联的做法仍暴露于主动中间人攻击。RFC 10042 复用这一周边结构，没有替客户端决定哪个名称、证书链或本地记录值得信任。

因此，交换哈希的范围要被如实保存。它纳入客户端和服务器标识串、两份 KEXINIT 负载、K_S、C_INIT、S_REPLY 与 K。这使会话密钥建立的字节序列可被绑定和核验。它没有纳入 SSH_MSG_USERAUTH_REQUEST、账户映射、服务器本地政策、通道请求或命令退出状态。SSH 架构把用户认证放在传输层之上，并明确由服务器本地政策决定接受哪些方法、允许哪些访问。

这不是要贬低混合交换。它在“现在收集、以后解密”的风险面前增加了一层独立的密码学基础，并将新方法接入既有 SSH 派生流程。真正的治理价值在于不让这一层吞没其他层：已验证的会话交换、主机密钥接受、用户认证、权限判定和后续动作，都应当各自保留能被追溯的证据。