OpenSSH 10.6 发布：为修复明文泄露漏洞禁用 LZ77 压缩，并拒绝含 $ 和 的命令行用户名
来源The New Stack查看原文
速览
- OpenSSH 10.6 主动禁用 LZ77 压缩以修复跨通道明文恢复漏洞
- 攻击需压缩开启且攻击者流量与机密共享同一多路复用 SSH 会话
- 该漏洞与 CRIME、BREACH 同属压缩侧信道攻击家族
- 命令行用户名中的 $ 和 被拒，配置文件 User 指令不受影响
- 后量子签名算法 ssh-mldsa44-ed25519 去掉实验后缀，旧密钥需重建
- scp -R 远程到远程复制进入淘汰流程，仍可用但会告警
- OpenSSH 因 AI 辅助漏洞挖掘增多，计划加快修复发布节奏
OpenSSH 10.6 于周二发布，包含两项明知会破坏兼容性但仍主动做出的安全改动。其一，禁用 SSH 压缩中使用的 LZ77 字典编码器——Ruhr University Bochum 的研究者 Fabian Bäumer 和 Marcus Brinkmann 在论文《Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels》中证明，多路复用通道共享同一压缩状态时，攻击者可通过向一个通道注入自选明文、观察加密流量长度变化，恢复同一会话中另一通道的机密数据。该攻击与针对 HTTP over TLS 的 CRIME、BREACH 属同一类，但需要攻击者流量与目标机密处于同一多路复用 SSH 会话中。在噪声最低的测试中，研究者从 26 字符字母表中恢复 8 字符机密，100 次试验的中位猜测次数为 276 次；在噪声更大的浏览器场景中升至约 27,600 次。其二，命令行传入的用户名中禁止出现 $ 和 ，以防这些字符经 ProxyCommand、Match exec 等指令被 shell 解释执行；通过配置文件 User 指令设置的用户名不受此限制。此外，10.6 还移除了混合后量子签名算法 ssh-mldsa44-ed25519 的实验性 @openssh.com 后缀（旧密钥需重新生成或删除），并开始淘汰用于远程到远程复制的 scp -R（仍可用但会告警，未来将被忽略）。
关键事实
- OpenSSH 10.6 于周二发布，维护者明确知晓两项改动会破坏现有功能
- 10.6 在 ssh 和 sshd 中禁用 LZ77 字典编码器，保留 Huffman 编码，压缩仍可用但效率下降
- 漏洞论文由 Ruhr University Bochum 的 Fabian Bäumer 和 Marcus Brinkmann 完成，编号 arXiv:2609.07709
- 最低噪声测试中，研究者从 26 字符字母表恢复 8 字符机密，100 次试验中位猜测次数为 276 次；浏览器场景约 27,600 次
- 两位研究者用 Claude Code 构建了全部三种攻击场景的概念验证实现
- 10.6 还致谢 Chris Rohlf 与 Claude、Anthropic Research 合作发现并修复的另外两个漏洞
本站视角
这次更新对国内做基础设施、CI/CD 和 Agent 工具的团队影响最直接。第一，任何在 SSH 层开启 Compression 的自动化流水线——尤其是跨公网、带宽受限环境下同步大量日志或构建产物的任务——升级后压缩效率会下降，需要把压缩上移到应用层（如 tar+gzip 后再传输），否则可能面临传输时间与成本上升。第二，用户名限制会打到一批「拼接式」脚本：CI 任务、内部运维平台、以及近期大量涌现的 Agent 工具，常把用户输入直接拼进 ssh 命令，一旦用户名含 $ 或 ，升级后会直接失败。这类代码本就有命令注入风险，OpenSSH 此举等于强制修复，短期会带来兼容性报错，长期是好事。第三，后量子签名算法去掉实验后缀意味着此前尝鲜生成的密钥需要重建，正在试点后量子 SSH 的团队要提前排期。我们的判断是：这是一次典型的「安全优先、兼容性让路」的发布，改动本身没有争议，LZ77 共享字典的设计缺陷是真实的，攻击虽需要较苛刻的前提（压缩开启 + 同会话多路复用 + 攻击者能注入明文），但修复成本低、收益明确，值得尽快跟进。真正值得关注的是发布说明里透露的信号：OpenSSH 明确提到 AI 模型正在被用于漏洞挖掘，并因此改变发布节奏。这意味着未来开源基础组件的安全补丁会更频繁、更碎片化，运维团队需要把「频繁小版本升级」纳入常态流程，而不是像过去那样攒着大版本一起升。需要指出的是，本次攻击的成功率数据来自研究者自己的论文与实验环境，276 次与 27,600 次中位猜测次数是在特定字母表和噪声条件下的结果，不能直接外推到真实生产环境；同时 OpenSSH 默认关闭压缩这一事实，也意味着实际暴露面比标题给人的印象要小。
背景与影响
SSH 可在一条加密连接上承载交互式 shell、端口转发、动态 SOCKS 代理等多种通道。当压缩开启时，这些通道共享同一压缩状态。LZ77 的工作方式是：遇到重复字节序列时不再重新编码，而是回指此前出现过的匹配序列。OpenSSH 将这份历史跨通道共享，因此攻击者可控的数据会改变同一会话中其他机密数据的压缩方式——当猜测命中机密的一部分时，产生的流量会略微变短，从而泄露信息。OpenSSH 默认关闭压缩，所以该攻击仅在用户主动开启压缩时有效。OpenSSH 选择了最直接的修复方式：彻底移除共享字典，在 ssh 和 sshd 中禁用 LZ77，仅保留 Huffman 编码。官方建议将压缩移到应用层处理，通常性能更好且不受此攻击影响。大多数交互式 SSH 会话可能感受不到差异，但在受限连接上传输大量可压缩数据的自动化任务会受影响，升级后可能需要把压缩从 SSH 移到应用中。用户名限制针对的是由外部输入拼接而成的命令，例如内部工具、CI 任务或 agent 执行 ssh "$INPUT_USER@host" 时，用户名可能进入 ProxyCommand、Match exec 等传给 shell 的命令中，$ 和 会变成 shell 语法。值得注意的是，本次发布发生在 OpenSSH 观察到越来越多用 AI 模型开展安全研究的背景下，项目警告不报告漏洞的攻击者「很可能也能发现这些 bug」，并计划比以往更频繁地发布修复，而不是等待常规发布周期。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
