摘要

  • RFC 10042 是2026年8月发布的 IETF 信息类 RFC，由 Panos Kampanakis、Douglas Stebila 与 Torben Hansen 共同署名，定义三种把 ML-KEM 与 P-256、P-384 或 X25519 结合的 SSH 密钥交换方法。
  • 混合交换的服务器响应仍包含主机公钥以及对交换哈希的签名；传输密钥启用后，SSH 还会另行认证用户。因此，KEX、服务器身份和用户身份必须分别取证。
  • AWS 的 SFTP 调试示例把三层结果写在不同日志行：混合 KEX、主机密钥算法与指纹，以及稍后发生的公钥用户认证。这比一个笼统的“量子安全 SSH”标签更适合作为审计模型。

打开 SSH 详细日志，最容易被忽略的不是某个算法名称，而是行与行之间的责任变化。

一行说明双方选择了什么密钥交换方法。另一行列出服务器主机密钥算法和指纹。更靠后的位置，服务器才报告用户以哪种方式通过认证。文件传输看起来是一项连续动作，协议却没有把三项判断交给同一个控制面。

RFC 10042 加固的是第一项。它规定 mlkem768nistp256-sha256、mlkem1024nistp384-sha384 和 mlkem768x25519-sha256 三个名称，分别把 ML-KEM 与 P-256、P-384 或 X25519 组成混合交换。最终 SSH 共享秘密同时吸收后量子与传统椭圆曲线的贡献。

目标是降低“现在收集、以后解密”的风险。攻击者可以先保存今天的加密会话，等待未来具备破解传统密钥建立的能力。混合方案使传输秘密不再只押注一种算法家族。这是一项重要成果，但它回答的仍是一个边界清楚的问题。

主机密钥仍在服务器响应中

RFC 10042 的报文结构没有隐藏这条边界。客户端发送传统与后量子的临时公开材料；服务器返回 ML-KEM 密文和传统临时公钥，同时还必须给出 K_S——服务器主机公钥——以及对交换哈希的签名。

混合秘密 K 是后量子秘密与传统秘密拼接后所得的哈希。交换哈希还覆盖双方软件标识、各自的 SSH_MSG_KEXINIT、主机密钥、混合交换值和 K。服务器用主机私钥签名这个哈希。

两项工作被同一 transcript 连接起来，却没有变成同一项工作。混合 KEX 让双方得到新的传输密钥；主机签名则表示某个服务器身份对这份 transcript 负责。客户端仍要回答：为什么相信眼前这把主机密钥属于目标服务器？

RFC 4253 在协商阶段就把它们拆成两张列表：kex_algorithms 与 server_host_key_algorithms。客户端可以查询 known_hosts、核对带外指纹、验证证书，或执行其他明示的信任策略。RFC 4253 也警告，未经验证便接受主机密钥，会使协议继续暴露于主动攻击。ML-KEM 无法替操作员补回一次被跳过的身份核验。

因此，服务器身份回执至少要保存主机签名算法、指纹或证书、信任来源、验证结果和轮换事件。只记录 KEX 名称，无法证明这些字段。

用户要在传输建立之后才能进门

当新传输密钥开始使用，信任方向随之反转。刚才是客户端识别服务器；接下来是服务器判断某个用户名能否访问指定服务。

RFC 4252 把用户认证定义为运行在 SSH 传输层之上的独立协议。实现必须支持 publickey，也可以支持密码、hostbased 或扩展方法。公钥请求包括用户名、服务、算法、用户公钥和签名。服务器不仅验证签名，还要确认这把钥匙是否被该账户接受，以及是否仍需第二种认证。

这里的公钥与服务器主机密钥都能产生签名，却属于不同主体。主机密钥让客户端识别服务器；用户密钥让服务器识别用户或自动化进程。authorized_keys、身份目录、停用账户、多因素要求、强制命令、SFTP 目录权限和特权边界都不会出现在 mlkem768x25519-sha256 这个字符串里。

企业可以先升级 SSH 库与 KEX 偏好，再迁移主机签名和用户凭据。这种分阶段安排并不矛盾。真正的问题是拿第一阶段的成功去替第二、第三阶段结账。

AWS 日志给出了三列表格

AWS Security Blog 的一篇 SFTP 文章提供了罕见的可运行证据。2023年的原始示例使用尚未标准化的 Kyber 方法名；2025年9月5日的更新说明，两项 AWS Transfer Family 安全策略已改用 ML-KEM，并列出后来写入 RFC 10042 的三个方法名。

旧日志不能被倒推成一条 RFC 10042 会话。它的价值在于展现 SSH 如何留下不同回执：日志先报告混合 KEX，再另列 ssh-ed25519 主机密钥算法和服务器指纹，稍后才显示用户通过 publickey 完成认证，随后打开 SFTP 会话。

审计员可以据此提出三个互不替代的问题：

  1. 客户端提出过哪些方法，双方最终实际选中了哪一种，是否到达 SSH_MSG_NEWKEYS？
  2. 哪把主机密钥签署了交换，客户端依据什么信任它？
  3. 哪个用户以哪种方法获得了哪个账户和子系统的权限？

最后的“已连接”增加了通道确实可用的证据，却不会自动证明文件权限合理、落盘数据加密、日志完整、备份安全或恢复有效。

从实验性 Kyber 名称切换到标准 ML-KEM 名称，还揭示了软件生命周期的现实。客户端、服务器、嵌入式设备和自动化脚本不会同日升级。版本、偏好顺序与回退策略决定每一条连接真正执行什么。IANA 登记表中的 SHOULD 是互操作坐标，不是全网普及率。

标准的价值恰好来自有限范围

Amazon Science 目前把 Panos Kampanakis 介绍为 AWS principal security engineer，工作涉及应用密码学、安全自动化与标准。2023年的 AWS 专访中，他主张盘点非对称密码使用、评估 SSH 等具体场景里的迁移影响，并为算法切换保留敏捷性；他也强调，从受控原型走到长期规模化支持并不简单。

这段履历解释了 RFC 的运营取向，却不能改写共同署名。Douglas Stebila 与 Torben Hansen 是共同作者。RFC 还感谢来自 AWS、OpenSSH、PuTTY 等方面的实现与审阅贡献。ML-KEM 来自 NIST 标准，IETF 过程和 IANA 注册表提供公共协议坐标。

RFC 10042 的成就在于把最低共同机制写得可测试：报文、混合器、编码、长度与公钥检查、每连接临时密钥、不得重用 ML-KEM 密文随机数，以及失败时必须断开的条件。实现者终于可以围绕同一份精确合同互测。

这与 Heng Lu 的“最低初始规范”原则相符。公共标准只需固定最小互操作边界，不必接管每个组织的信任库、账户数据库和恢复制度。未来决策留给实际运行并承担后果的主体。

“运行代码优先”进一步要求回执来自真实结果：客户端与服务器版本、提出与选中的 KEX、主机算法和指纹、信任判断、加密与 MAC、NEWKEYS、用户认证方式、授权结果、已打开通道、rekey、回退、失败以及探测盲区。

RFC 10042 让第一份回执更强。尊重这项成果的方式，不是把它扩写成全会话结论，而是让另外两份回执继续等待自己的证据。

来源