Ubuntu 上的后量子 SSH：默认启用了什么

Post-quantum SSH 的变化

对大多数用户而言，post-quantum SSH 已经默认启用，无需进行任何配置。当前版本的 OpenSSH 客户端连接当前版本的 OpenSSH 服务器时，默认会选择混合 post-quantum 密钥交换。因此，会话密钥可以抵御这样的攻击者：攻击者今天记录您的网络流量，并在多年后解密这些流量。这种保护确实有效，但其范围小于“quantum-safe SSH”这一说法所暗示的范围。

先介绍两个术语。SSH（secure shell）是用于登录服务器的协议。密钥交换通常写作“kex”，是每个 SSH 连接的第一步：两端协商一个共享密钥，然后使用该密钥加密后续的所有内容。发生变化的是密钥交换部分。其他部分没有变化。

不要信任本页，请运行这些命令

下面列出的每个算法名称，都来自您可以自行运行的命令。这是有意为之。默认值会随每个 OpenSSH 版本变化，因此两年前编写的指南可能会列出您的计算机已不再优先使用的算法，而且无法发现这一点。掌握这些命令后，您就不再需要查阅介绍此主题的文章，包括本页。

先查看您的构建版本支持哪些功能。

ssh -V
ssh -Q kex

ssh -V 会输出一行以 OpenSSH_ 开头的版本信息，后面是 Ubuntu 软件包后缀和 OpenSSL 版本。ssh -Q kex 会逐行输出一个密钥交换算法。在支持后量子密码的构建版本中，您会在列表中看到 mlkem768x25519-sha256 和 sntrup761x25519-sha512@openssh.com 等名称，它们与 curve25519-sha256 等经典算法并列。

构建支持的算法不等于实际提供的算法

这是大多数文章都会忽略的区别。ssh -Q kex只回答一个问题：这个二进制文件能够执行什么操作。它没有回答你真正关心的问题：这次连接实际会提出什么算法。两份列表并不相同，而旧建议造成的实际问题就出在它们之间的差异上。

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host>会在应用~/.ssh/config和/etc/ssh/ssh_config后，打印客户端针对该主机的有效配置。sshd -T对服务器执行相同操作。两者都会按优先级打印一行kexalgorithms，其中排在第一位的名称就是该端的首选项。这一行才是实际在线路上传输的内容。

这种差异并非理论上的问题。OpenSSH 8.5 于 2021-03-03 发布，其中加入了sntrup761x25519-sha512@openssh.com，但特意将其排除在默认列表之外。在该版本中，ssh -Q kex会显示该算法，而ssh -G不会显示。这意味着该二进制文件支持后量子密钥交换，但没有任何连接会主动请求使用它。

读取连接协商出的算法

ssh -v example.com 2>&1 | grep 'kex: algorithm'

在当前客户端与当前服务器之间运行时，输出如下：

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 是一种混合算法。它使用参数集 768 的 ML-KEM（模块格密钥封装机制，已标准化为 FIPS 203），并结合 X25519 椭圆曲线 Diffie-Hellman，然后将两者的输出混合到会话密钥中。

连接到较旧的服务器时，可能会看到：

debug1: kex: algorithm: curve25519-sha256

该名称不包含后量子部分。curve25519-sha256 单独使用椭圆曲线 Diffie-Hellman，大型量子计算机可以破解它。这正是默认算法发生变化的原因。

一条协商规则解释了为什么单台旧机器会限制整个会话。客户端按首选顺序发送算法列表，服务器也发送自己的列表。最终选择的是客户端列表中同时出现在服务器列表里的第一个名称。客户端的首选顺序优先，因此两端中较旧的一端决定协商能推进到列表中的哪个位置。升级笔记本电脑，并不会让它与从未识别 ML-KEM 的服务器建立后量子会话。

了解 ssh -v 不只是为了这一行，因为登录被直接拒绝时，同样的输出还可用于排查 Permission denied (publickey) 错误。

去掉 grep 后，ssh -v 会显示协商的其余内容，其中包括下一节要介绍的那一行：

debug1: kex: host key algorithm: ssh-ed25519

哪个 OpenSSH 版本将混合密钥交换设为默认

上游发行说明给出了清晰的时间顺序。日期比版本号更重要，因为它们说明这项功能已经在后台运行了多长时间。

• 8.5 于 2021-03-03 发布，加入了 sntrup761x25519-sha512@openssh.com，但默认禁用。
• 9.0 于 2022-04-08 发布，将其启用。说明中写道，OpenSSH 将“默认使用混合 Streamlined NTRU Prime + x25519 密钥交换方法”。这是后量子密钥交换成为常规选项的版本。
• 9.9 于 2024-09-19 发布，加入了第二个选项 mlkem768x25519-sha256。同一版本为旧方法分配了 IANA 注册名称 sntrup761x25519-sha512，因此较新的构建会同时列出这两种名称。
• 10.0 于 2025-04-09 发布，将 mlkem768x25519-sha256 设为密钥协商的默认方法。
• 10.1 于 2025-10-06 发布，新增客户端警告：当连接协商出不包含后量子部分的密钥交换方法时，客户端会发出警告。此功能由 ssh_config 中的 WarnWeakCrypto 选项控制，并默认启用。

请记住 2022 年 4 月这个日期。任何运行 OpenSSH 9.0 或更高版本的两台机器，自那时起就一直在执行后量子密钥交换，无需配置，也不会向输入 ssh 的用户提示。

哪些 Ubuntu 版本包含该功能

Ubuntu 会在发布时固定 OpenSSH 版本，之后只将安全修复回移植到该版本中，而不会更改版本号。因此，所运行的 Ubuntu 版本决定了默认算法。请使用 ssh -V 检查当前机器，不要直接依赖版本列表。截至 2026 年 8 月，软件仓库中的版本如下：

• 22.04 LTS 包含 1:8.9p1。该版本早于 9.0 的默认设置，因此标准安装会协商使用 curve25519-sha256。
• 24.04 LTS 包含 1:9.6p1。该版本晚于 9.0 且早于 9.9，因此默认值为 sntrup761x25519-sha512@openssh.com，并且不支持 ML-KEM。
• 25.10 包含 1:10.0p1，其默认值为 mlkem768x25519-sha256。
• 26.04 LTS 包含 1:10.2p1，默认使用 mlkem768x25519-sha256，并会警告未采用后量子算法的连接。

下面通过一对实际机器进行说明。一台 26.04 笔记本电脑连接到一台 24.04 服务器。客户端的首选算法 mlkem768x25519-sha256 不在 9.6 服务器的算法列表中。服务器支持的下一个后量子算法是 sntrup761x25519-sha512@openssh.com，ssh -v 报告的就是该名称。虽然服务器使用 2024 年构建的版本，但密钥交换仍采用后量子算法，而且双方都未进行任何配置。

22.04 的情况相反，这也准确说明了为什么单独查看 ssh -Q kex 会产生误导。OpenSSH 8.9 已知 sntrup761x25519-sha512@openssh.com 这个名称，因此该机器上的 ssh -Q kex 会列出它。但默认提议中不包含该算法，所以协商最终使用 curve25519-sha256。从 OpenSSH 10.1 或更高版本的客户端连接时，会显示以下信息：

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

该警告反映的是目标服务器的情况，而不是客户端的情况。解决方法是升级服务器。设置 WarnWeakCrypto no 只会隐藏该消息，不会改变连接。

为什么采用混合方案，以及“现在收集、以后解密”是什么意思

这种威胁的模式很简单。攻击者可以查看网络流量，并在今天记录加密字节后将其保存下来。他们现在无法读取这些内容。他们会一直保存，直到出现足以破解 X25519 的大型量子计算机，然后再读取这些内容。这称为“现在收集、以后解密”，也称为“现在存储、以后解密”。攻击者当前不需要采取复杂手段，只需要磁盘空间和耐心。

这个问题存在于加密中，而不存在于签名中，这种不对称性决定了后续设计。只要密文中的数据仍然敏感，已记录的密文就一直具有价值。签名只需在验证时保持不可伪造即可。如果有人在 2035 年破解签名算法，他可以在 2035 年冒充服务器，但无法回溯伪造 2026 年的登录记录。因此，必须先修复密钥交换，签名部分可以稍后处理。

混合方案表示两种算法同时运行，并将两者的结果共同用于生成会话密钥。攻击者要恢复 mlkem768x25519-sha256 背后的秘密，必须同时破解 ML-KEM 768 和 X25519。采用这种组合是有意为之的：ML-KEM 的历史远短于 X25519，接受密码分析人员攻击的时间也少得多。因此，即使在新算法中发现缺陷，也不会损害你已经获得的保护。

哪些内容受到保护，哪些内容不受保护

密钥交换受到保护。用于加密会话的共享密钥来自混合交换，因此，即使有人今天记录了该会话，量子计算机出现后，这些记录也不会变得可读。

主机密钥不受保护。debug1: kex: host key algorithm: ssh-ed25519 行指定的是经典签名，rsa-sha2-512 和 ECDSA（椭圆曲线数字签名算法）类型也是如此。拥有可用量子计算机的攻击者可以伪造该签名并冒充您的服务器，但这只能发生在未来进行实时连接时，无法用于攻击现在记录的流量。

您的登录密钥同样不受保护。~/.ssh/id_ed25519 中的密钥属于同一种经典签名，适用相同的原理。今年保护该密钥的因素，是它存储在哪里以及谁可以读取它。因此，合理管理 SSH 密钥比本页列出的任何算法名称都更能降低您的实际风险。

这两项都不需要您采取措施，因为目前没有可替换的方案。OpenSSH 已表示将在未来版本中支持后量子签名。在该功能发布之前，OpenSSH 没有后量子主机密钥类型，也没有后量子用户密钥类型，ssh-keygen 也无法提供这类密钥。任何指导您生成此类密钥的教程，描述的都是尚不存在的软件。

同一台服务器上的 TLS 是另一个问题，答案也不同。TLS（传输层安全）是 Web 服务器在 443 端口上使用的协议，其代码库和开发计划都不同。升级 OpenSSH 不会改变 TLS。如果您在同一台 VPS 上为私有服务运行自签名证书，其签名和密钥交换由 OpenSSL 与 Web 服务器决定，因此应单独根据该软件栈进行评估。

现在应采取的稳妥措施

保持 OpenSSH 为最新版本，然后到此为止。这就是解决此问题的完整策略。sudo apt update && sudo apt upgrade 会将 OpenSSH 保持在 Ubuntu 版本自带的版本上；升级到更新的 Ubuntu 版本，才会将 OpenSSH 升级到更新版本。启用 无人值守安全升级 后，系统会自动安装这些补丁，无需您记得手动执行。为了追踪某个算法名称而从源代码构建 OpenSSH，得不偿失，因为这样会放弃发行版针对服务器上暴露面最大的服务提供的安全更新。如果您仍要获取源代码，请在构建前使用其公布的校验和验证下载内容。

不要手写 KexAlgorithms 行。这是唯一一个肯定会使情况变糟的操作。2018 年的加固指南会提供一份在 2018 年适用的列表，将其粘贴到 sshd_config 中会替换默认列表，而不是在其基础上追加。此后新增的所有算法都会被排除，因此原本可以自行协商 mlkem768x25519-sha256 的服务器，会悄然降级到固定列表中仍然可用的算法。对您接手的任何服务器运行 sudo sshd -T | grep -i '^kexalgorithms'。如果该行比同一版本全新安装中的对应行更短，说明有人固定了算法列表。

如果您确实有理由修改列表，请追加内容，而不是替换列表。OpenSSH 将开头带 + 的内容解释为追加，将开头带 - 的内容解释为移除，将开头带 ^ 的内容解释为移到前面。

KexAlgorithms ^mlkem768x25519-sha256

在依赖配置文件前先测试它。sudo sshd -t 会解析配置；配置有效时不输出任何内容。KexAlgorithms 行如果指定了构建版本不支持的算法，sshd 将无法启动。在远程服务器上，这意味着您将无法重新登录，因此操作时请保留第二个会话。双方的算法列表没有交集时，客户端会明确提示：

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

对于“量子安全”宣传，应将其理解为针对某一层的声明。供应商称产品具备量子安全能力时，描述的是其指定的某一层，而该层通常是某处的密钥交换。请确认算法名称及其适用的协议。对于 2026 年 8 月的 OpenSSH，准确的说法是：密钥交换采用混合后量子方案，而签名仍采用经典算法。任何更宽泛的说法，都应提供一个可在 ssh -Q kex 输出中找到的名称。

继续做好这些看似枯燥的工作。后量子密钥交换无法解决可猜测的密码问题，也无法防止私钥被复制到之后遭窃的笔记本电脑中。真正导致服务器被攻破的通常就是这些问题，而在 VPS 上进行标准 SSH 加固 仍然最为重要。如果本页介绍的协商步骤您不熟悉，SSH 在连接时执行的操作介绍了本页假定您已了解的各个阶段。

FAQ

我的 SSH 连接已经具备后量子安全性了吗？

运行 ssh -v yourserver 2>&1 | grep 'kex: algorithm'，查看它输出的名称。mlkem768x25519-sha256 和 sntrup761x25519-sha512@openssh.com 是混合后量子密钥交换算法。curve25519-sha256、ecdh-sha2-nistp256 以及任何 diffie-hellman-group 名称都属于经典算法。通信两端都必须使用提供后量子名称的版本，因为协商会选择客户端首选且服务器也支持的算法，所以版本较旧的机器会限制可用上限。

哪个 OpenSSH 版本将后量子密钥交换设为默认？

OpenSSH 9.0 于 2022-04-08 发布，并将 sntrup761x25519-sha512@openssh.com 设为默认密钥交换算法。OpenSSH 9.9 于 2024-09-19 发布，加入了 mlkem768x25519-sha256；OpenSSH 10.0 于 2025-04-09 发布，并改为将该算法设为默认。OpenSSH 10.1 于 2025-10-06 发布，开始在连接未协商使用任何一种后量子算法时发出警告。使用 ssh -Q kex 和 ssh -G <host> 检查当前构建的行为，因为所用的 Ubuntu 版本决定了你可以使用其中哪些算法。

我应该生成后量子 SSH 密钥吗？

不应该，因为 OpenSSH 没有这种密钥类型。目前的后量子实现只覆盖密钥交换，不需要你提供密钥文件，也不需要任何配置。主机密钥和登录密钥仍使用 Ed25519、RSA 等经典签名算法。上游项目表示，后量子签名将在未来版本中提供。继续使用 Ed25519 密钥，并保护好其存储位置。

为什么 ssh 警告我的连接不具备后量子安全性？

OpenSSH 10.1 及更高版本会在协商的密钥交换不包含后量子部分时输出 ** WARNING: connection is not using a post-quantum key exchange algorithm.。该警告针对服务器，而不是客户端，因为你的客户端提供了后量子名称，但服务器没有接受其中任何一个。升级服务器上的 OpenSSH，或检查是否有人在其 sshd_config 中设置了 KexAlgorithms 行，从而排除了现代算法名称。设置 WarnWeakCrypto no 只会隐藏消息，连接的安全性不会因此改变。