移除 OpenSSH 中 DSA 支持的时间线
OpenSSH 计划在 2025 年初彻底移除对旧版 DSA 公钥算法的支持，此前该算法已多年默认禁用，而 NIST 也早已建议逐步淘汰 1024 位 DSA。评论者在权衡删除过时加密所带来的安全与维护收益——包括简化密钥处理并为后量子算法做准备——以及对仍需连接无法升级的硬件、工业系统和空气隔离环境的组织所造成的实际影响。主流观点是，这类遗留需求应通过固定旧版 OpenSSH、在容器中封装或使用替代客户端来处理，而不应期待上游无限期维护脆弱的算法。
弃用时间线与历史
- OpenSSH 计划分阶段移除 DSA：
- 2024-03：DSA 在编译时可选，默认启用。
- 2024-06：DSA 在编译时可选，默认禁用。
- 2025-01：从 OpenSSH 中移除 DSA。
- 评论者指出，这延续了长期以来的指导意见：
- NIST 建议在 2010 年前停止使用 1024 位 DSA。
- OpenSSH 从未支持更大的 DSA 密钥，并且早在 OpenSSH 7（2015）中就已默认禁用 DSA。
移除 DSA 的理由
- 主要理由包括：
- SSHv2 中的 DSA 仅限于 1024 位公钥 / 160 位私钥，被认为较弱。
- 维护遗留代码成本高，尤其是在重构期间以及添加新算法时（例如可能的后量子签名）。
- 老旧、很少测试的代码路径被视为安全风险。
对遗留系统的影响
- 一些用户仍需要 DSA 才能访问：
- 老旧网络硬件、交换机、BMC、iLO、电信设备、工业控制系统、旧版 RHEL，以及合作伙伴系统。
- 担忧在于：“无法修复”的系统可能会继续服役数十年，尤其是在工业和关键基础设施中。
- 也有人认为这些系统应该被隔离、空气隔离，或者替换；如果它们无法更新，就不应暴露在更广泛的网络中。
责任与权利诉求
- 一个强烈的主题是：开源维护者没有义务无限期支持过时的加密算法。
- 反方观点：把弃用成本下放会增加总工作量，而且在高度监管或官僚化的环境中会很困难。
- 有人认为，与其完全移除，不如采用“危险/遗留”标志或插件模型。
替代方案与变通方法
- 建议包括：
- 保留旧版 OpenSSH 客户端（可能放在 VM、容器或专门的“legacy jump host”中）。
- 使用保留旧协议的发行版软件包（例如 ssh1 客户端）。
- 使用其他 SSH 实现（Dropbear、PuTTY），或者在严格受控的网络中甚至使用 telnet。
- 有人担心在现代系统上编译非常旧的 OpenSSH，以及遗留客户端的安全性。
相关加密讨论
- 澄清了 DSA 参数以及 SSHv2 规范中其固有的 160 位私钥。
- 讨论了其他密钥类型：RSA、ECDSA、Ed25519。
- 另有一条分支提到主要云厂商：AWS 增加了 Ed25519 支持；据称 Azure 和一些 GCP 组件仍然不支持。