- OpenSSH 10.6 于 2026 年 10 月 6 日发布,修复了十一个与安全相关的缺陷。Debian Security Tracker 为此列出了十个 CVE 编号,从 CVE-2026-106552 到 CVE-2026-106589。
- 对于 Debian 12 和 Debian 13,这十个目前全部标记为“vulnerable”,那里还没有修复后的软件包。到目前为止只有 Debian unstable 已修复。
- 这十条描述中没有一条提到登录前的远程代码执行。在更新之前,
sshd_config中的三项设置可以釜底抽薪,让服务器端的漏洞失去成立的前提。
在几乎每台 Linux 服务器上,SSH 都是唯一的入口。当 OpenSSH 项目发布了一个包含整批安全修复的版本,而你所用的发行版还没有对应的软件包时,就会出现一个很实际的问题:哪些事你今天就能做,哪些必须等?
问题是什么
OpenSSH 10.6 的发行说明在“Security”下列出了十一项。项目方写道,最近收到了非常多的缺陷报告,其中许多是借助 AI 工具发现的。由于同样的缺陷往往很快又被独立地发现第二次,团队打算暂时更频繁地发布较小的版本,而不是把修复攒到下一个大版本。对运维者来说,这意味着:短期内还会有更多安全版本。
软件包的状态我们于 2026 年 10 月 7 日在 Debian Security Tracker 上查看过。那里登记了十个 CVE,对于 bookworm(Debian 12)和 trixie(Debian 13),全部标记为“vulnerable”。
| 组件 | 缺陷 | 影响对象 |
|---|---|---|
| sshd | 失败的 GSSAPI 尝试所产生的凭据会被保留,并在另一次成功登录之后可被使用(CVE-2026-106553、CVE-2026-106555) | 设置了 GSSAPIAuthentication yes 的服务器,通常即使用 Kerberos 的服务器 |
| sshd 和 ssh | 共用压缩造成的旁路:如果有人能在一个会话中注入自己的数据,就可以通过加密数据包的长度,猜出同一会话中另一个通道里的机密(CVE-2026-106582) | 启用了压缩、且混合传输可信数据与外来数据的连接 |
| sshd | authorized_keys 中的关键字 restrict 对隧道转发不起作用(CVE-2026-106586) | PermitTunnel 不为 no 的服务器 |
| sshd | 在 Match 块中,对 AuthorizedPrincipalsFile 等部分选项,值“none”被当作文件名读取(CVE-2026-106587) | 含有此类 Match 规则的服务器 |
| sshd 和 ssh | 压缩后的数据包没有被限制在最大数据包大小之内(CVE-2026-106585) | 使用压缩的连接 |
| sftp | 恶意服务器在递归复制时可以把文件写到目标文件夹之外(CVE-2026-106552) | 你作为客户端,从陌生服务器下载时 |
| ssh | 命令行用户名中的 $ 和 \ 可能经由 ProxyCommand 或 Match exec 进入 shell(CVE-2026-106583) | 把来自外部来源的用户名传给 ssh 的脚本 |
| ssh-keygen | 夏令时换算错误,证书最多会提前或推迟一小时过期(CVE-2026-106584) | 签发 SSH 证书的人 |
第十个 CVE(CVE-2026-106589)涉及 QNX 6 之类的平台,在这些平台上会话进程会继续以 root 权限运行。对 Linux 服务器来说,它无关紧要。
我们检查了什么
关键在于,这些前提条件在一台正常配置的服务器上是否根本就满足。为此,我们查阅了手册页中的默认值,并在一台未经改动、使用 OpenSSH 9.6 的 Ubuntu 24.04 上读取了这些设置:
- 服务器端的
GSSAPIAuthentication默认是no。如果你不使用 Kerberos,这两个 GSSAPI 缺陷就与你无关。 PermitTunnel默认是no。只有当你有意允许了隧道,restrict缺陷才会生效。Compression在服务器端默认是yes,在客户端是no。也就是说,只有客户端提出请求时才会压缩,例如使用ssh -C。但一旦压缩,这个旁路原则上就成立。
结果是:对于使用默认设置的服务器,主要剩下压缩和客户端一侧的缺陷。这两者都可以在没有新软件包的情况下缓解。
sshd_config,或者使用了会修改它的模板,那么唯一重要的是 sshd -T 在你的服务器上输出什么。如何检查你的服务器
- 确认版本。
低于 10.6 的版本都受影响,除非你的发行版已把修复向后移植。对 Debian 而言,Security Tracker 会显示从哪个软件包版本起是这种情况。ssh -V apt policy openssh-server - 读取实际生效的设置。
sudo sshd -T | grep -Ei '^(gssapiauthentication|compression|permittunnel) ' - 在更新之前加固。 在
/etc/ssh/sshd_config中,或在/etc/ssh/sshd_config.d/下的单独文件中添加:
只有在你确实使用 Kerberos 或 SSH 隧道时,才需要省略Compression no GSSAPIAuthentication no PermitTunnel noGSSAPIAuthentication和PermitTunnel。 - 测试配置,然后重新加载。
保持当前会话开着,在第二个窗口中重新登录,确认成功后再关闭第一个窗口。sudo sshd -t && sudo systemctl reload ssh - 更新一出来就安装。
sudo apt update sudo apt install --only-upgrade openssh-server openssh-client
如何确认已经生效
重新加载之后,sshd -T 必须显示新的值,并且在第二个窗口中的登录必须成功。软件包更新之后,apt policy openssh-server 会显示已安装的版本。把它与 Security Tracker 中登记为“fixed”的版本进行对比。
tar czf 或 zstd。OpenSSH 项目也是这样建议的,而且这样做不受这个旁路影响。那你自己的电脑呢?
其中三个缺陷涉及客户端。在你的操作系统提供更新之前,建议只对你信任的服务器使用 sftp -r 和 scp -r,并且不要在脚本中把来自外部输入的用户名传给 ssh。顺带一提,从 10.6 起,scp -R 会输出一条警告:项目方打算取消这个选项。
除此之外,如何用密钥代替密码并配合 fail2ban 来保护 SSH 访问,请看我们的文章正确保护 SSH 访问。如果你的旧系统上更新失败,从 Debian 12 升级到 Debian 13那篇文章会对你有帮助。
