OpenSSH Server 强制启用后量子密码（PQC）实操部署流程

从 OpenSSH 9.9（2024 年 10 月）到 10.4（2026 年 7 月），OpenSSH 用两年时间完成了从引入 ML-KEM 混合密钥交换到实验性支持 ML-DSA 签名认证的跨越。本文提供一份可直接跟随的实操部署流程——从版本检查、配置加固到强制策略，覆盖关键交换与身份认证两个维度。

━━━ ━━━ ━━━

OpenSSH Server 强制启用后量子密码 (PQC) 实操部署流程为什么现在就要做？

2026 年的现实比预想来得更快：

• \"Harvest Now, Decrypt Later\" 已不是理论——对手正在大规模存储 SSH 握手密钥交换的加密流量，等待量子计算机成熟后批量解密
• Google 已秘密实现 ECDLP 量子破译电路（2026 年 3 月可在 2 个月内被独立复现改进）——意味着整个 ECC 基础设施的理论安全边际被压缩
• OpenSSH 10.1+ 默认发出无 PQC 警告——如果你的服务器还跑着旧版，客户端日志里已悄悄出现警告行

好消息是：ML-KEM（FIPS 203，即昔日的 CRYSTALS-Kyber）从 OpenSSH 10.0 起已是默认密钥交换算法。你只需要正确配置，不需要额外打包安装第三方库。

第一步：检查当前版本与状态1.1 检查 OpenSSH 版本

在目标服务器上执行：

ssh -V
# 输出示例：
# OpenSSH_10.4p1, OpenSSL 3.4.1 15 Jan 2026

版本对照表：

1.2 检查当前密钥交换算法

# 查看 sshd 实际启用的 KEX 算法

sshd -T | grep -i "kexalgorithms"

如果输出中没有 mlkem768x25519-sha256，说明你的 sshd 配置覆盖了默认值，且可能禁用了后量子算法。

1.3 查看客户端连接使用的算法

从另一台机器连接后，在服务器上检查：

# 查看 SSH 日志（RHEL/Debian 位置可能不同）
sudo grep "kex" /var/log/auth.log | tail -5

或在客户端执行：

ssh -v user@server 2>&1 | grep "kex"

预期输出中应出现：

debug1: kex: algorithm: mlkem768x25519-sha256

如果只看到 curve25519-sha256 或 sntrup761x25519-sha512，说明部署了但未使用最新混合算法。

第二步：升级 OpenSSH（如版本过旧）2.1 RHEL / Rocky / Alma 系列

# RHEL 10 已内置 OpenSSH 10.x 并默认启用 ML-KEM
sudo dnf check-update openssh
sudo dnf update openssh-server openssh-clients

RHEL 10.1+（2026 年 5 月发布）进一步将 ML-KEM 列为最高优先级。

2.2 Debian / Ubuntu 系列

# Ubuntu 25.10+ 和即将发布的 26.04 LTS 默认使用 mlkem768x25519
sudo apt update
sudo apt install openssh-server openssh-client

2.3 源码编译（迫不得已时的备选）

如果需要从源码编译最新版本：

# 下载 OpenSSH 10.4
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-10.4p1.tar.gz
tar xzf openssh-10.4p1.tar.gz
cd openssh-10.4p1

# 编译时 ML-KEM 默认开启，不需要额外 configure 选项

./configure --prefix=/usr --sysconfdir=/etc/ssh

make -j$(nproc)
sudo make install
sudo systemctl restart sshd

第三步：配置 sshd 强制启用 PQC 密钥交换3.1 推荐配置：明确指定 KEX 算法（排除经典算法独立使用）

编辑 /etc/ssh/sshd_config：

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)
sudo vi /etc/ssh/sshd_config

在文件中设置（或修改）以下行：

# 仅允许混合 PQC 密钥交换算法

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512

# 或更稳妥--保留纯 X25519 以防客户端太旧
# KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

推荐策略：先用更宽松的列表（含 curve25519-sha256 作为兜底），观察一周无异常后再收紧。

3.2 OpenSSH 10.1+ 的静默策略（可选）

在 sshd_config 中添加：

# 10.1+ 新增：拒绝没有 PQC 的连接（谨慎使用！）
# RefuseConnection yes

# 或更温和：仅日志警告
# LogLevel VERBOSE

⚠️ 重要警告：RefuseConnection 会拒绝任何不支持 PQC 密钥交换的客户端连接。在部署前，务必确认所有需要连接的客户端都已升级至 OpenSSH 9.9+。

3.3 验证 KEX 算法排序优先级

# 确认 sshd 实际加载的配置

sshd -T | grep kexalgorithms

应该看到你刚才配置的算法列表，且 mlkem768x25519-sha256 在第一位。

第四步：生成并部署 PQC 主机密钥（高级配置）4.1 当前限制

OpenSSH 尚未默认使用 PQC 算法（如 ML-DSA）作为主机密钥签名算法。主机密钥仍然使用 RSA 或 Ed25519。但以下措施可以提高安全性：

4.2 推荐：优先使用 Ed25519 主机密钥

# 删除较弱的 RSA 主机密钥（如有）
# 注意：如果已有正在使用的 RSA 密钥，请先确认所有客户端已知其指纹
# sudo rm /etc/ssh/ssh_host_rsa_key*

# 生成 Ed25519 密钥（更高安全性，更短签名）
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

4.3 OpenSSH 10.4 实验性：ML-DSA 混合主机密钥

OpenSSH 10.4（2026 年 7 月发布）引入了实验性的 ML-DSA 44 + Ed25519 混合签名密钥支持。要使用这一功能：

# 生成 ML-DSA 44 + Ed25519 混合主机密钥（实验性）
sudo ssh-keygen -t ml-dsa-44-ed25519 -f /etc/ssh/ssh_host_ml-dsa-44-ed25519_key -N ""

然后在 sshd_config 中启用：

# 启用 ML-DSA 混合主机密钥（10.4+ 实验性）

HostKey /etc/ssh/ssh_host_ml-dsa-44-ed25519_key HostKey /etc/ssh/ssh_host_ed25519_key # 保留作为兜底

注意：ML-DSA 签名密钥实验性支持在 10.4 中仍然标记为实验特性，生产环境建议先做充分测试。

第五步：客户端配置（同样重要）

PQC 需要服务端和客户端两端同时支持。在需要连接服务器的客户端机器上：

5.1 Linux / macOS 客户端

# 确认版本
ssh -V

# 客户端升级到 9.9+（推荐 10.0+）
sudo apt install openssh-client   # Debian/Ubuntu
sudo dnf update openssh-clients   # RHEL

# 检查连接是否使用 PQC
ssh -v user@server 2>&1 | grep "kex: algorithm"
# 应输出: mlkem768x25519-sha256

5.2 Windows 客户端

• OpenSSH for Windows（Windows 10/11 内置）：需升级到 Windows 2026 年累积更新包中的 OpenSSH 10.x 版本
• Termius：自 2026 年 Q1 版本起已支持 mlkem768x25519-sha256

第六步：验证部署成功6.1 连接全链路验证

# 从客户端执行详细连接
ssh -vv user@server 2>&1 | grep -E "(kex|kex_alg|server_host_key)"

期望输出：

debug2: kex_parse_kexinit: mlkem768x25519-sha256 debug1: kex: algorithm: mlkem768x25519-sha256 debug1: kex: host key algorithm: ssh-ed25519

6.2 强制回退测试（可选）

# 如果启用了 RefuseConnection，测试不支持的客户端行为
ssh -oKexAlgorithms=diffie-hellman-group14-sha256 user@server
# 预期：连接被拒绝

6.3 安全合规审计脚本

保存为 /usr/local/bin/check_ssh_pqc.sh：

#!/bin/bash
# 检查 OpenSSH 服务器 PQC 合规状态

echo "=== SSH PQC 合规检查 ==="
echo ""

# 版本检查
VERSION=$(sshd -V 2>&1 | head -1)
echo "版本: $VERSION"

# KEX 算法检查
KEX=$(sshd -T | grep kexalgorithms)
echo "密钥交换: $KEX"

if echo "$KEX" | grep -q "mlkem768x25519"; then
echo "✅ ML-KEM 混合密钥交换已启用"

else

echo "❌ ML-KEM 混合密钥交换未启用"

fi

# 主机密钥检查
echo ""
echo "主机密钥:"
for key in /etc/ssh/ssh_host_*_key.pub; do
KEYTYPE=$(ssh-keygen -lf "$key" 2>/dev/null | awk '{print $4}')
echo "  $key → $KEYTYPE"

done

# 连接测试
echo ""
echo "连接测试 (localhost):"
if echo "$KEX" | grep -q "mlkem768x25519"; then
ssh -oKexAlgorithms=mlkem768x25519-sha256 -oConnectTimeout=5 localhost "echo '✅ PQC KEX 连接成功'" 2>&1

fi

chmod +x /usr/local/bin/check_ssh_pqc.sh
sudo /usr/local/bin/check_ssh_pqc.sh

第七步：注册到监控系统（Cron + 日志）

将 PQC 状态检查加入 cron，确保不会因为配置漂移而回退：

# 每天凌晨 4 点检查一次
echo "0 4 * * * root /usr/local/bin/check_ssh_pqc.sh > /var/log/ssh_pqc_check.log 2>&1" | sudo tee /etc/cron.d/ssh_pqc_check

完整部署路线图（可供参考）

常见问题（FAQ）

Q: ML-KEM 混合密钥交换的安全性如何？

A: 它是混合构造：mlkem768（后量子 ML-KEM）+ x25519（经典 ECDH）。即使量子计算机未来攻破 ML-KEM，x25519 层仍会提供经典安全保护。反之亦然。这是最保守的安全设计。

Q: 如果我升级后客户端还是旧版，会无法连接吗？

A: 取决于你的 KexAlgorithms 设置。如果只保留了混合算法（如 mlkem768x25519-sha256），OpenSSH 9.9 以下版本的客户端确实无法连接。推荐策略：逐步收紧——先用宽松列表过渡一段时间。

Q: OpenSSH 10.4 的 ML-DSA 签名能否替代 SSH 密钥认证？

A: 不能。10.4 的 ML-DSA 签名支持仅限于主机密钥（host key），用于验证服务器身份。客户端用户的身份认证密钥（public key authentication）仍然使用经典的 RSA/Ed25519 密钥。PQC 用户认证密钥的支持仍在开发中。

参考文献

1. OpenSSH 10.4 Release Notes. (2026, July). *OpenSSH 10.4*. https://www.openssh.com/txt/release-10.4
2. OpenSSH 10.0 Release Notes. (2025, April). *OpenSSH 10.0*. https://www.openssh.com/txt/release-10.0
3. OpenSSH 9.9 Release Notes. (2024, October). *OpenSSH 9.9*. https://www.openssh.com/txt/release-9.9
4. National Institute of Standards and Technology (NIST). (2024, August). *FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)*. https://doi.org/10.6028/NIST.FIPS.203
5. National Security Agency (NSA). (2025). *Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)*. https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
6. Google Quantum AI. (2026). *Quantum Circuits for ECDLP: Reproduction and Improvement*. https://postquantum.com/security-pqc/google-ecdlp-circuits-reproduced-open/
7. Red Hat Enterprise Linux 10.2 Release Notes. (2026, May). *Post-Quantum Cryptography in RHEL 10*. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/10/html/security_hardening/
8. Ubuntu 26.04 LTS. (2026, Q2). *Post-Quantum SSH Key Exchange Default*. Ubuntu Release Notes.
9. Termius. (2026). *PQC Support in Termius SSH Client*. https://termius.com/blog/post-quantum-cryptography-ssh

━━━ ━━━ ━━━

*本文为纯技术操作指南，基于 OpenSSH 官方发布说明、NIST FIPS 203 标准及相关发行版文档编写。操作前请确保已备份 sshd_config 并在非生产环境充分测试。最后更新：2026-07-07。*

五大战线、三条路径、一项禁令：美国战争部《后量子密码战略》深度解读

招商银行QKD试点：量子金融安全的架构深演与估值逻辑

内核纪元新篇章：Linux 7.0 深度技术解析与架构演进

2026 网络安全十大趋势与实战应对方案

从 SNI 泄漏到 ECH 全链路加密：OpenSSL 4.0 强制驱动的 DNS 架构演进

零信任安全架构全景解析：从概念到落地的完整指南（2026版）

libssh2 漏洞深度解读：SSH 库的"重症监护室"时刻