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

后量子 SSH 有哪些变化

后量子 SSH 已经为大多数用户默认启用，用户无需进行任何配置。当前版本的 OpenSSH 客户端连接当前版本的 OpenSSH 服务器时，默认会选择混合后量子密钥交换。因此，即使攻击者今天记录网络流量，并在多年后解密，这个会话密钥仍能抵御此类攻击。此保护确实有效，但其覆盖范围小于“量子安全 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 的服务器建立使用该算法的会话。

删除 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 检查当前机器，不要直接依赖版本列表。截至 August 2026，软件仓库中的版本如下：

• 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 的量子计算机，然后再读取这些内容。这称为“现在窃取、以后解密”（harvest now, decrypt later），也称为“现在存储、以后解密”（store now, decrypt later）。攻击者当前不需要采取复杂手段，只需要磁盘空间和耐心。

这个问题存在于加密中，而签名不存在，因此其他设计都由此决定。只要密文中的数据仍然敏感，已记录的密文就持续具有价值。签名只需在验证时保持不可伪造即可。如果有人在 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 会让您使用 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 会隐藏该消息，但连接的安全性不会改变，仍与之前一样弱。