OpenSSH 10.6 禁用部分压缩并出于安全原因拒绝某些用户名

OpenSSH 10.6 包含两项可能破坏部分既有使用场景的安全变更：禁用负责在 SSH 压缩中构建重复序列字典的 LZ77 组件，以及在通过命令行传递用户名时拒绝包含 $ 和\ 符号的用户名。项目开发者是在了解部分环境和工具需要调整的情况下作出这一决定的。

为什么要削弱 SSH 压缩？

一个 SSH 会话可以承载交互式终端通道、端口转发或动态 SOCKS 代理。启用压缩后，各通道共享同一个压缩状态。Ruhr University Bochum 的研究人员 Fabian Bäumer 和 Marcus Brinkmann 证明，攻击者可以向一个通道注入自行选择的文本，并监控加密流量，从而推断同一会话另一通道中传输的机密数据。

该攻击利用 LZ77 内存机制：它会重新使用此前出现过的序列，而不是对其进行完整编码。当攻击者的猜测与机密的一部分匹配时，压缩结果可能会略短，从而提供有助于恢复数据的信号。这种方法属于 CRIME 和 BREACH 攻击家族，但需要特定条件：启用 SSH 压缩、能够控制部分流量，并且机密与攻击者控制的通道位于同一个多通道 SSH 会话中。

在噪声较低的测试中，研究人员在 100 次实验中以中位数 276 次猜测，从包含 26 个字符的字母表中恢复了一个八字符机密。在噪声更大的基于浏览器的场景中，猜测次数上升到约 27,600 次。根据源材料，概念验证模型使用 Claude Code 构建。

压缩方面实际会发生什么变化？

OpenSSH 保留了 Huffman 编码，但在 ssh 和 sshd 中都禁用了 LZ77 部分。因此，压缩不会完全消失，但效率会降低。项目表示，常见的交互式会话通常不会明显察觉差异；而通过带宽有限的连接传输大量可压缩数据的自动化任务可能会受到影响。

OpenSSH 的建议是将压缩转移到应用层，因为这种方式通常更高效，也不会受到此类攻击的影响。实际上，依赖 SSH 压缩的自动化系统所有者应在升级后测量传输大小和执行时间，然后确定是在发送数据前压缩数据更合适，还是继续依赖 SSH 压缩。

用户名与自动化路径

10.6 版本拒绝通过命令行传递的用户名中的 $ 和\ 符号。此举针对内部工具、CI 任务和代理程序，这些程序会构建类似 ssh "$INPUT_USER@host" 的命令；随后用户名可能会进入 ProxyCommand 或 Match exec 等指令，在这些位置，这些符号可能被解释为 shell 构造的一部分，而不是普通数据。

通过 SSH 配置文件中的 User 指令指定用户名时，不适用同一限制。因此，包含这些符号的合法账户仍可通过这种方式使用；但直接通过命令行传递这些用户名的脚本和工具可能需要修改。这发生在 OpenSSH 10.3 中一项相关修复之后：当时 shell 字符的检查时机过晚，使其能够进入 ssh_config 的扩展路径。

可能影响工作流程的其他变更

• 后量子混合签名算法 ssh-mldsa44-ed25519 不再使用实验性后缀 @openssh.com，这意味着使用此前实现创建的密钥需要重新生成或删除。
• 项目开始为停止支持 scp -R 从远程主机复制到远程主机做准备。该选项在 10.6 版本中仍可用，但会发出警告，未来计划忽略它。

这些变化表明，当自动化使用暴露出数据泄露或命令注入路径时，与既有行为的兼容性不再是绝对优先事项。不过，实际限制并不相同：压缩数据泄露风险需要特定会话和条件，而用户名被拒绝则可能立即出现在依赖外部输入的脚本中。因此，运营团队需要测试升级、审查 SSH 命令的构建方式，并在大范围采用该版本前核验密钥和复制选项。