把libc类型写进资产台账

这次 CVE-2026-123158 一出来，我们组干的头一件事其实不是打补丁，而是集体登录机器数 libc。原因很尴尬：台账里写着“Alpine 3.x”“Ubuntu 22.04”，但光看这个标签，谁也答不出这台机器到底链接的是 musl 还是 glibc、sshd 有没有走 PAM。于是我们只能一台台敲 ldd --version、ldd /usr/sbin/sshd | grep -i pam，边敲边骂自己当初为什么不多记两列字段。

这件事让我彻底认了个道理：资产台账只记发行版和版本号，在漏洞面前基本等于没记。因为这次的问题成立要看一串条件——sshd 低于 10.6p2、实际用 musl、没启用 PAM、账户配置又落在特定组合。发行版名字只是这条链的起点，拿它做判断，要么漏掉真正危险的主机，要么把一堆默认使用 glibc 加 PAM 的系统白白卷进变更流程。

更反直觉的是，“发行版标签”本身就不牢靠。有人在 glibc 系统上编译了不带 PAM 的 sshd，或者把 Alpine 的二进制塞进别的根文件系统，标签当场失效。容器更别提了，镜像里到底装没装 openssh-server、装的是哪个变体包，台账上一片空白。

所以我现在逢人就说，台账里至少得补这么几列：libc 类型、sshd 是否链接 PAM、usepam 的实际生效值、sshd 实际版本与包来源。判断运行时别偷懒，readlink -f /proc/$(pidof sshd)/exe 看一下进程真正跑的是哪个二进制，sshd -T | grep -i '^usepam' 看配置生效值，比翻包管理器记录靠谱得多。还有，Alpine、OpenWrt、Buildroot、Yocto 这些 musl 环境，建议单独打个标，下次出事直接能筛出来。

另外我把容器基础镜像的 OpenSSH 版本也纳进了构建基线。以前觉得容器临时得很，不用管；现在明白，镜像里装了 openssh-server 就有暴露面，跟它是不是容器没关系。

说白了，台账不是做给审计看的摆设。它真正的价值在事故当天：能少打几十个电话、少登录几十台机器，直接筛出该优先处置的那批主机。补两列字段的功夫，比事后逐台核验便宜太多了。