OpenSSH 10.1警告：3亿台服务器还在用"裸奔"加密

2025年4月，OpenSSH 10.0把抗量子算法mlkem768x25519-sha256设为默认。三个月后，10.1版本就要对没升级的服务器亮黄牌了。

这个警告不是吓唬人的。全球约有3亿台SSH服务器，其中相当比例仍在使用传统密钥交换算法。攻击者今天截获的加密流量，十年后用量子计算机解密——这叫"先存后破"攻击。

从"默认开启"到"强制警告"的三年

OpenSSH 9.0在2022年4月首次默认启用抗量子算法sntrup761x25519-sha512。当时很多人没当回事：量子计算机？科幻片吧。

但开发团队算的是另一笔账。SSH会话的保密期往往很长——服务器配置、数据库密码、核心代码，这些信息的敏感周期可能跨越十年以上。如果密钥交换算法被攻破，历史流量全部裸奔。

2025年4月的10.0版本做了两件事：一是新增mlkem768x25519-sha256算法，二是把它设为默认。mlkem768基于NIST标准化的Kyber方案，sntrup761则来自NTRU-Prime项目。两者都是"混合"设计：传统椭圆曲线（X25519）+抗量子算法，兼顾兼容性和安全性。

10.1版本的警告机制是临门一脚。用户连接非抗量子服务器时，终端会弹出三行提示：

** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html

警告可关，但默认开启。这个设计很产品经理：不阻断业务，但让你看见。

量子威胁的时间表比想象中近

业界对"密码学相关量子计算机"（CRCQ）的到达时间估计，从5年到20年不等。主流观点指向2030年代中期——也就是十年后。

听起来还远？考虑两个因素。

第一，数据保鲜期。医疗记录、金融交易、国家机密，有些数据需要保密30年以上。今天用传统算法加密的流量，2035年可能就是明文。

第二，"先存后破"的隐蔽性。攻击者不需要现在解密，只需要存储。等量子计算机成熟后批量处理，历史数据一锅端。这种攻击方式在密码学社区被称为"harvest now, decrypt later"，中文圈常译作"收割现在，解密未来"。

SSH的密钥交换环节尤其脆弱。整个会话的保密性都系于初始握手阶段协商出的对称密钥。一旦密钥交换被攻破，后续所有加密通信形同虚设。

OpenSSH核心开发者Damien Miller在邮件列表中解释过这个设计逻辑：「我们不希望用户在2025年建立的连接，在2035年变成公开可读。」

升级阻力：兼容性与性能的双重考验

抗量子算法并非没有代价。

mlkem768的公钥大小约为1184字节，传统X25519只有32字节。握手阶段的网络开销明显增加，高延迟网络环境下感知明显。部分嵌入式设备和老旧路由器，处理大体积密钥时CPU占用飙升。

更麻烦的是服务端升级意愿。企业内网的SSH服务器、IoT设备、工业控制系统，很多跑在十年前的Linux发行版上。管理员的心态是：能连就行，动它干嘛。

OpenSSH的警告策略针对的就是这种惰性。它不阻断连接，但把"你的会话可能在未来被解密"这件事摊到终端上。对于需要合规审计的企业，这条警告足够触发升级流程。

配置层面，客户端可通过WarnWeakCrypto no关闭警告。但安全团队通常不会允许这种操作——留下配置变更记录，等于主动承认风险。

行业跟进：谁已经动了，谁在观望

云厂商的动作最快。AWS EC2的SSM Session Manager、Google Cloud的OS Login、Azure的Bastion，底层都依赖OpenSSH或兼容实现。三大云在2024-2025年间陆续完成抗量子算法部署，用户无感知切换。

GitHub和GitLab的SSH服务也在2024年支持了混合抗量子密钥交换。开发者push代码时，如果本地OpenSSH版本够新，自动启用保护。

滞后的是企业内网和长尾设备。某头部安全厂商的扫描数据显示，截至2025年Q1，Alexa排名前10万网站对应的SSH服务中，仍有约34%未启用任何抗量子算法。金融、医疗、政府行业的内部系统，升级周期以年为单位。

OpenSSH的警告机制会加速分化：对外服务的服务器被迫跟进，内网孤岛继续裸奔。这种"外紧内松"的格局，和TLS 1.3的推广历程如出一辙。

一个值得注意的细节：OpenSSH 10.1的警告只针对密钥交换（Kex），不涉及数字签名。SSH的用户认证环节仍广泛使用RSA/ECDSA签名，这部分的抗量子迁移更复杂——需要新密钥类型、证书链改造、用户习惯重塑。OpenSSH 9.2实验性支持了ML-DSA签名，但默认关闭。

密钥交换先走一步，是因为它的升级对用户透明。签名算法的全面替换，可能是下一个五年的战役。

你的SSH客户端升级到10.0了吗？下次连服务器时，留意一下有没有那三行黄色警告——它可能是2035年的你，发来的求救信号。