上海企业服务器只开了密钥登录就安全吗？OpenSSH 这个绕过打的正是没密码的账户

直接回答：不安全——只禁用密码登录挡不住这个洞，它绕过的恰恰是“没有密码的账户”，先查 sshd 有没有跑在 musl 上。

上海不少企业的服务器接入是这么收紧的：关掉密码登录、只留密钥、禁止 root 远程。这套做法在过去十年基本够用。11 月 5 日，OpenSSH 发布 10.6p2，修了一个编号 CVE-2026-123158 的漏洞——它绕过的不是密码强度，而是“这个账户本来压根没有密码”这一条路径。公开不到 9 小时，就有蜜罐被打穿拿到 root。

一、事实：分数不高，条件很窄，但恰好撞在常见配置上

先把可核实的部分列清楚：

• 编号与性质：CVE-2026-123158，上游昵称“SSHole”，CVSS 3.1 为 8.1，归类 CWE-394（意外状态码或返回值）。2026 年 11 月 5 日公开，同日发布 10.6p2 修复。
• 受影响面：10.6p2 之前的 OpenSSH，且必须同时满足两个前提——链接的是 musl libc、没有启用 PAM。Alpine、OpenWrt、Buildroot、Yocto 属于这一类；RHEL、Ubuntu、Debian、SUSE 等 glibc 发行版不在范围内。
• 触发条件：目标主机上存在密码字段为星号的账户，且至少有一个账户的密码哈希为 5 号或 6 号算法格式。Alpine 默认的 root 账户密码字段就是一个星号，正好是前者。
• 已经在用：CVE 公开后不到 9 小时，威胁情报公司 Previdian 在运行 Alpine 与 OpenSSH 的蜜罐上观测到首例利用，并确认获取 root，来源 IP 归属日本。

图1：三个前提同时成立才有风险

真正值得记的是这个结论：它不是“全行业 OpenSSH 都有洞”，而是一类配置的洞——而这类配置恰好是容器基础镜像的默认值。

二、为什么“没密码”反而成了入口

设了密码的账户要撞库，没设密码的账户按理说谁也进不去。这个洞把后者的假设推翻了。

没有 PAM 时，sshd 校验口令依赖 C 库的 crypt 函数。musl 在哈希失败时返回一个星号；而“禁止登录”的账户在 shadow 里的密码字段，本身就是一个星号。两者字符串相同，比较即通过。口令长度窗口写在 CVE 记录里，257 到 1024 字节这一段会走到失败分支。

再往上一层，根因是 2016 年那次修复。当年为堵住用户名枚举的时序侧信道（CVE-2016-6210），OpenSSH 改成对“没有可用哈希”的账户也做一次假哈希，让响应时间对齐。这个补丁在 glibc 下没问题，在 musl 下把假哈希做成了星号。

这件事真正的教训：加固动作本身是一个假设，换一个运行时就可能不成立。

三、上海企业最容易漏的四处

漏点一：资产台账只到虚拟机，不到容器镜像。 跑在 Alpine 上的构建机、K8s 节点、边缘盒子，多数不在“服务器清单”里。容器里拿到 root 之后，若该容器是特权模式或挂了宿主机的容器运行时接口，影响面会扩到宿主机与同宿主机的其他容器。→ 台账加一列：镜像基础层是 glibc 还是 musl。

漏点二：星号账户没人认领。 root 的星号、镜像自带的免密账户、早期留下的应用账户——它们本是“禁止登录”的标记，在这个洞下变成可登录。→ 逐条导出密码字段为星号的账户，确定归属与用途，无主的冻结。

漏点三：以为“只允许密钥登录”就已经关了密码。 规范写法是把 PasswordAuthentication 设为 no，但有些镜像的默认值是 yes，改动加在别的文件里、未生效。条件成立与否看的是最终生效值。→ 读实际生效配置，不看配置文件。

漏点四：日志只看失败，不看“不该成功的成功”。 这类登录在日志里是密码认证成功的记录，属于成功条目，不进失败统计。→ 告警规则补一条：星号账户出现密码认证成功。

图2：五步排查，先查条件再升版

四、三种环境，三种动作

五、五步排查，顺序有讲究

1. 查版本：确认 OpenSSH 是否低于 10.6p2，同时看发行版包版本，两者可能不一致。

2. 查 libc 与 PAM：确认是 musl 还是 glibc；确认 sshd 配置里 PAM 是否启用。两个条件缺一，风险不成立。

3. 查星号账户：列出 shadow 中密码字段为星号的账户，逐个认领。

4. 关密码认证再升版：PasswordAuthentication 设为 no 并重载；Alpine 用户升到 3.21.10、3.22.8、3.23.8、3.24.4 或 edge 的修复包。

5. 查历史登录：在 /var/log/messages 或 auth.log 中找星号账户的密码认证成功记录。若无法排除，按已失陷处置。

六、威丽能承接的部分

上海威丽信息科技有限公司是上海本地化的企业 IT 运维与系统集成服务商。这类“藏在运行时里”的漏洞，难点不在打补丁，在于先找全资产：服务器与虚拟机的版本台账、容器镜像基础层盘点、边缘设备固件核查、sshd 生效配置核查、登录日志审计与告警规则调整，以及升级窗口的值守。服务以 10 分钟极速响应 / 2 小时现场服务 为标准，覆盖上海全域。

七、三个常见误区

• “我们只用密钥，不用密码，跟我们无关”：恰恰相关。这个洞打的就是“没有密码”的账户。
• “glibc 系发行版，跳过”：结论成立，但结论要靠查 libc 得出，不能靠“应该是”。
• “升完版就完了”：容器镜像要重建才生效，改完配置不重载也不生效。

八、常见问题

问：我们全在内网，也要处理吗？

答：要。这类绕过只需要能连上 SSH 端口，内网横向移动阶段同样成立。

问：容器里出问题，影响有多大？

答：取决于容器权限。特权容器或挂载宿主机容器运行时接口的容器，等于宿主机失守。

问：升版要停机吗？

答：重载 sshd 会断开现有会话，建议放在维护窗口；容器镜像则按发布流程滚动替换。

结语

这次值得记住的不是 8.1 这个分数，而是漏洞的位置：它长在“禁止登录”这个标记上。企业做安全加固最常做的三件事——关密码、禁 root、只留密钥——恰好把资产推进了这个洞的判定条件里。真正的动作只有一个：把 libc、PAM、星号账户、生效配置这四项查清，再决定是否升版。

上海威丽信息科技有限公司 · 深耕上海本地企业 IT 服务近 20 年 · 累计服务 2500+ 家企业 · 服务热线 400-880-7581 · 技术热线 021-51697581-605/610 · 官网 https://www.vilitech.com

数据来源

• OpenSSH 10.6p2 发行说明（2026 年 11 月 5 日），https://www.openssh.org/txt/release-10.6p2
• NVD 漏洞记录 CVE-2026-123158，https://nvd.nist.gov/vuln/detail/CVE-2026-123158
• Alpine Linux 安全公告《OpenSSH password authentication bypass》（2026 年 11 月 5 日），https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
• 香港电脑保安事故协调中心 HKCERT 安全公告《OpenSSH Security Restriction Bypass Vulnerability》（2026 年 11 月 6 日）
• Previdian 威胁情报观测：CVE 公开后 9 小时内蜜罐被利用并获取 root（2026 年 11 月 5 日）