请先做一件事：如果你运行的是 Alpine Linux 或其他 musl libc、未启用 PAM 的 Linux 系统，并且开启了口令认证，请立即将 PasswordAuthentication 设为 no，或先关闭这些系统的 SSH 服务。

2026 年 11 月 5 日，OpenSSH 发布 10.6p2，修复一个可远程绕过口令认证的高危漏洞，编号 CVE-2026-123158，社区昵称 SSHole（写作 *sshole），CVSS v3.1 评分 8.1。漏洞由 Wakefield 公司的研究者 Özgün Kültekin 发现并报告。

需要说明的是：这个漏洞的根因并不在 OpenSSH 自身，而是 musl C 库、OpenSSH 十年前的时序攻击防御、以及 Unix shadow 文件约定三者叠加产生的"边界失效"。正因如此，仅凭 OpenSSH 版本号无法判断是否受影响，必须同时核对 libc 类型与 PAM 配置。

一、漏洞概况

二、为什么这个漏洞值得优先处置

2.1 它绕过的是一个"绝不应该被绕过"的前提

Linux 系统中，如果一个账号不允许用口令登录（例如只允许密钥登录的服务账号、系统内置账号），其 /etc/shadow 的口令字段会被设置为单个星号 *——这是 Unix 沿用几十年的约定：该账号永远无法通过口令认证。

而这个漏洞打破的正是这条约定：攻击者不需要知道任何口令、不需要窃取密钥，只要提交一个超长口令，就能登录进去。

2.2 三个"各自都正确"的设计撞在了一起

这是本次漏洞最值得记录的部分——它不是某个程序员写错了一行代码，而是三个独立团队、相隔多年的三个正确决策，在特定组合下互相抵消：

第一环：musl libc 的 256 字节截断（2012 年）。
musl 的 crypt() 为防止超长口令导致的 CPU 耗尽攻击，会将输入截断在 256 字节；当输入超过这个长度、无法计算哈希时，它返回字符串 * 作为错误标识（而不是返回 NULL）。

第二环：OpenSSH 的时序攻击防御（2016 年，CVE-2016-6210）。
当年发现 sshd 会通过响应时间泄露"用户名是否存在"：不存在的用户秒回，存在的用户要跑几十到几百毫秒的哈希计算。为消除这个时间侧信道，OpenSSH 在 auth-passwd.c 中加入了"假哈希"逻辑——当账号没有可用口令哈希时，借用系统中另一个真实账号的 salt 与哈希参数，仍然对攻击者输入的密码跑一遍 crypt()，使失败登录的耗时与真实账号一致。

第三环：shadow 文件的 * 约定。
在被借用的那个账号上，如果系统里恰好存在另一个带 $5$（SHA-256）或 $6$（SHA-512）哈希的账号，OpenSSH 就能借到合法 salt。

三环相撞： 攻击者提交一个 257—1024 字节的口令 → musl 的 crypt() 因超长而失败，返回 * → OpenSSH 把这枚"错误标识"当作哈希结果 → 与目标账号 shadow 中存储的 * 完全相等 → sshd 判定认证成功。

一句话概括：一个"哈希失败"的错误返回值，恰好等于"账号禁用口令"的存储值，于是错误被当成了正确。

三、受影响条件：四个条件必须同时成立

不是所有 OpenSSH 都受影响，需要同时满足以下条件：

1. OpenSSH 版本 低于 10.6p2；
2. 运行在 musl libc 的 Linux 上（glibc 不受影响）；
3. 未启用 PAM 进行口令认证；
4. PasswordAuthentication 为 yes；
5. 系统中存在至少一个口令字段为 * 的账号，且存在至少一个带 $5$ 或 $6$ 哈希的账号（攻击者还需能确定一个允许登录的目标账号）。

明确不受影响的情况：

• 基于 glibc 的发行版（CentOS、RHEL、Ubuntu、Debian、麒麟、统信等主流服务器系统）；
• 使用 PAM 验证口令的系统；
• 非 Linux 系统（OpenBSD、FreeBSD 等）；
• Dropbear 等其他 SSH 实现；
• 使用 ! 锁定的账号（! 与 * 不相等，不满足上述比较）。

这条很重要： 本次漏洞对国内大多数使用 glibc 发行版的单位不构成直接风险。真正需要紧张的是容器镜像、Kubernetes 节点、嵌入式与 IoT 设备、以及基于 Alpine 的构建机与网关——这些恰恰是最容易被资产台账漏掉的部分。

四、在野利用：披露 9 小时内已被打

威胁情报公司 Previdian 向媒体披露，在 CVE 公布后不到 9 小时即记录到首次利用尝试，并在其运行 Alpine Linux 与 OpenSSH 的蜜罐上确认取得 root 权限。攻击者通过超长口令通过认证后，在非交互式 SSH 会话中执行了 id、uname、hostname 等侦察命令，来源为单一 IP，地理位置指向日本。

同时，公开的漏洞复现环境（PoC）已在多个平台出现，HKCERT、ENISA 与多国 CERT 均已发布高危通告。

需要客观说明两点：一是该漏洞的 CVSS 攻击复杂度标记为"高"（AC:H），因为它依赖特定的配置与账号组合，并非"任意 OpenSSH 都能打"；二是一旦条件成立，利用门槛极低——只需一个超长字符串。

五、排查：四步确认是否暴露

在任意一台疑似受影响的主机上依次执行：

# 1. 确认 OpenSSH 版本（低于 10.6p2 需继续判断）
ssh -V

# 2. 确认 libc 类型（musl 才有风险）
ldd --version 2>&1 | head -2
# 或直接看系统：cat /etc/os-release | grep -i alpine

# 3. 确认是否启用 PAM 与是否开启口令认证
sshd -T 2>/dev/null | grep -iE "passwordauthentication|usepam|kbdinteractive"

# 4. 检查是否存在 * 口令字段的账号（这就是可被登录的目标）
sudo awk -F: '$2=="*"{print $1}' /etc/shadow

日志排查（判断是否已被利用）：

# Alpine 系通常日志在 /var/log/messages
sudo grep -i "Accepted password" /var/log/messages /var/log/auth.log 2>/dev/null

重点关注：本不该接受口令登录的账号（root、alpine、各类只允许密钥登录的服务账号）出现了 "Accepted password" 记录。

此外建议检查：who / last 的异常登录、~/.ssh/authorized_keys 是否被追加陌生公钥、/etc/passwd 是否新增账号、doas/sudo 配置是否被改动、以及是否存在异常的计划任务与持久化项。

Alpine 官方建议：如果无法排除某次登录的可疑性，应按主机已失陷处理。

六、处置：升级 + 临时缓解 + 失陷排查

6.1 立即缓解（无法即时升级时）

在 sshd_config 中设置：

PasswordAuthentication no

然后重启 sshd。OpenSSH 项目负责人 Damien Miller 在公告中的原话是："如果你运行的是 musl libc 且未启用 PAM 的 Linux 系统（Alpine Linux 是其中之一），请停止阅读，立即设置 PasswordAuthentication=no 或关闭这些系统的 SSH。"

6.2 根治：升级到修复版本

升级后必须重启 sshd 服务（rc-service sshd restart 或 systemctl restart sshd），并确认新进程已加载。

注意容器场景： 基于 Alpine 的镜像需要重新构建，仅升级宿主机或运行中的容器不够；Kubernetes 节点上的镜像需逐个排查基础镜像版本。

6.3 一个容易被忽略的高危点：Alpine 云镜像

Alpine 安全公告指出，3.18.11 至 3.24.3 的 tiny-cloud 镜像内置了一个名为 alpine 的用户，并配置了免密 doas（即具备管理权限）。

这类镜像在首次启动时是安全的，但一旦主机上出现任何 $6$ 哈希（例如管理员为控制台设置了一个口令），漏洞条件即告成立——攻击者可利用超长口令直接登录这个具备管理权限的账号，等同于 root 级失陷。

建议： 使用过上述版本云镜像的实例，逐台核查并升级；已设置过控制台口令的实例，按"可能已失陷"排查。

七、同期 OpenSSH 的其他漏洞

本次 10.6p2 是安全缓解版本，此外 11 月初 SUSE 等厂商的安全公告还汇总了 OpenSSH 的另外一批问题，同样建议一并处理：

八、关于这次漏洞的三点观察

第一，AI 正在改变漏洞披露的节奏。
OpenSSH 在 10.6p2 的发布说明中明确写道：团队近期收到大量由 AI 模型发现或借助 AI 完成的安全报告；并且多次观察到"由 AI 工具发现的问题，随后被另一位研究者独立重新发现"——这说明不报告的对手同样可能发现这些问题。因此 OpenSSH 决定放弃长时间保密，改为更频繁地发布版本，尽快把修复送到用户手里。这个判断值得所有做安全运营的人重视：从漏洞公开到你被打的时间窗，正在以小时计。

第二，资产台账的盲区就是风险的落点。
本次受影响的是 Alpine——它几乎不出现在传统服务器资产清单里，却大量存在于容器基础镜像、K8s 节点、CI 构建机、路由与 IoT 固件中。如果只查"服务器清单"，大概率会漏掉真正暴露的那一批。

第三，十年前的补丁也可能是今天的入口。
2016 年为修复时序侧信道而加的"假哈希"逻辑，在当时是完全正确的工程决策；十年后它成了绕过认证的最后一环。这提醒我们：安全改造要定期回看，尤其是那些"为了兼容或为了性能"而做的妥协性设计。

九、建议的处置顺序

通用加固建议： SSH 一律禁止 root 直接登录、禁用口令认证、管理端口不对公网开放、统一经跳板机与堡垒机接入。这几条如果早就做到位，本次漏洞对绝大多数单位来说是"无需处置"。

我公司可协助开展容器镜像与基础镜像梳理、SSH 服务暴露面排查、批量升级与配置收敛、失陷主机取证与清理等工作。如需协助，欢迎联系。

联系电话：0351-5255612（此为我公司唯一对外联系电话）
官方网站：www.sxslz.com（我公司对外邮箱后缀均为 @sxslz.com）
投诉与举报渠道：ts.sxslz.com

参考资料

1. OpenSSH 10.6p2 发布说明，2026 年 11 月 5 日（openssh.com/releasenotes.html）
2. CVE-2026-123158 记录；ENISA EUVD-2026-117552 / NCSC-2026-0469，2026 年 11 月 6 日
3. Alpine Linux 安全公告及各分支修复版本（3.21.10 / 3.22.8 / 3.23.8 / 3.24.4、edge 10.6_p2-r0）
4. Özgün Kültekin（Wakefield）漏洞分析与复现说明
5. Previdian 威胁情报关于首次在野利用的披露（The Hacker News 报道）
6. HKCERT、SUSE 安全公告 SB2026110120（2026 年 11 月 1 日）等厂商通告
7. 公开复现环境：github.com/predkambrij/sshhole-repro、github.com/leonjza/sshhole-lab

本文整理自官方发布说明与公开技术分析，仅供安全防护参考。具体处置请结合自身环境评估，版本号以各厂商官方公告为准。