openssh 安全漏洞

2023年7月，全漏OpenSSH 9.3p1发布，全漏修了一个叫CVE-2023-38408的全漏漏洞。这个漏洞在ssh-agent转发功能里，全漏攻击者能通过它执行远程代码。全漏听起来挺吓人，全漏但实际利用条件比较苛刻——需要受害者主动连接到攻击者控制的全漏服务器，并且agent转发已开启。全漏那段时间我刚好在给几个客户的全漏服务器做安全审计，发现八成以上的全漏机器还跑着8.x版本，压根没升级。全漏

OpenSSH的全漏问题往往不在主程序本身，而是全漏那些“顺手打开”的附加功能。比如X11转发、全漏agent转发、全漏端口转发，默认配置里很多是关的，但运维人员为了图方便，经常手动打开。一旦打开，攻击面就扩大了。2024年初曝出的CVE-2024-6387（regreSSHion）更典型——这是OpenSSH服务端的一个信号处理竞争条件漏洞，影响8.5p1到9.8p1之间的版本。攻击者不需要认证，就能在特定条件下触发远程代码执行。Qualys的研究团队花了不到两周就写出了利用代码，虽然实际利用需要反复尝试，成功率不高，但足以让所有跑着glibc的Linux服务器紧张起来。

有意思的是，这个漏洞其实是2006年一个老漏洞的回归。当年CVE-2006-5051被修复后，2020年一次代码重构又把问题带了回来。这种“修了又回来”的情况在OpenSSH历史上不止一次。代码库太老，分支太多，很多补丁只打在特定版本上，下游发行版再各自打补丁，最后谁也不知道某个文件到底修没修干净。我见过一台CentOS 7的机器，openssh版本显示7.4p1，但实际编译进去的补丁列表长得像超市小票，连维护的人都说不清状态。

配置错误比漏洞本身更常见。PermitRootLogin yes、PasswordAuthentication yes、空密码、弱密钥——这些才是日常扫描器最先撞上的东西。去年帮一个客户做应急响应，攻击者就是靠一个允许密码登录的SSH端口，用hydra跑了三天，撞进了一台跳板机。那台机器上authorized_keys里塞了二十多把陌生公钥，全是攻击者留的后门。OpenSSH的日志里其实有记录，但没人看。

另一个容易被忽略的点是密钥管理。很多人把私钥直接放在~/.ssh/id_rsa，不加密，权限设成644。一旦主机被入侵，攻击者拿到私钥就能横向移动。我见过一个开发团队，十几个人共用一把私钥，离职半年的人还能登进生产环境。OpenSSH本身支持证书认证、FIDO/U2F硬件密钥，但这些功能用的人太少。大家还是习惯ssh-keygen一路回车。

版本升级这件事，在容器环境里更麻烦。很多基础镜像为了体积，把openssh-server精简掉了，但sshd又跑在宿主机上。Kubernetes节点上的sshd版本往往和镜像里的不一致，安全扫描器报的漏洞和实际运行的不是一回事。我试过用Trivy扫一个节点，报了十几个OpenSSH相关CVE，结果一查，一半是误报——因为宿主机上的sshd是静态编译的，根本不加载那些有问题的库。

说回CVE-2024-6387。修复方式很简单，升级到9.8p1或打发行版补丁。但真正麻烦的是那些不能重启sshd的环境——比如远程数据中心里的老设备，或者嵌入式系统。有人想用livepatch热修复，但glibc层面的竞争条件很难通过内核热补丁解决。最后只能上防火墙规则，限制源IP，或者干脆把SSH端口换个非标准号。这些招数治标不治本，但总比什么都不做强。

OpenSSH快25岁了，代码质量在开源项目里算好的，但架不住功能多、历史包袱重。每次出漏洞，官方响应都很快，但下游的碎片化让修复变得漫长。我的建议很直接：能用密钥就别用密码，能关转发就关转发，能上硬件密钥就上，版本至少保持在9.x以上，日志每周翻一次。别等扫描器报警了才想起来升级。