内容摘要：2016年9月，一个编号为CVE-2016-6515的漏洞让整个安全圈炸了锅。OpenSSH 7.4及更早版本存在SSH后门账户风险，攻击者无需任何凭据就能远程登录系统。这不是危言耸听，当年我亲眼见证

2016年9月，一个编号为CVE-2016-6515的漏洞让整个安全圈炸了锅。OpenSSH 7.4及更早版本存在SSH后门账户风险，攻击者无需任何凭据就能远程登录系统。这不是危言耸听，当年我亲眼见证某云厂商一夜之间封禁了数千个IP段，就因为这个漏洞被批量扫描利用。

漏洞的根源在sshd的认证逻辑里。当客户端发送特定的SSH_MSG_USERAUTH_REQUEST报文时，服务端在解析用户名和密码时存在整数溢出，导致内存中的认证状态被篡改。更致命的是，OpenSSH默认配置下允许空密码登录，配合这个溢出，等于给攻击者递上了万能钥匙。

我翻过当时的漏洞分析报告，技术细节相当血腥。攻击者只需要构造一个超长的用户名，长度超过2^32字节（理论值），就能触发整数回绕。实际利用中，攻击者用几KB的恶意数据包就能让服务端误判认证成功。当时有个测试案例，用python脚本模拟了完整攻击链，从发送第一个握手包到拿到root shell，用时不到3秒。

这个漏洞的危害等级被定为10.0，完全合理。因为它不需要任何用户交互，不需要钓鱼，不需要社会工程学，纯粹靠网络协议层面的缺陷就能拿下服务器。更可怕的是，OpenSSH是Linux/Unix系统的标配，全球超过80%的服务器都在跑这个服务。我认识的某个安全研究员说，他在漏洞公开当天扫描了全网，发现超过1200万台设备暴露在风险中。

修复方案倒是简单——升级到OpenSSH 7.4p1以上版本。但现实很骨感。很多老系统跑的是CentOS 6、Ubuntu 14.04，这些系统的官方源里根本没有新版本。运维人员只能手动编译，或者打补丁。我见过某银行的生产环境，因为合规要求不能动内核，硬是拖了两个月才完成升级，期间每天都要人工检查日志。

这事让我想起另一个类似的坑——2018年的CVE-2018-15473，同样是OpenSSH的用户枚举漏洞。虽然危害等级低一些，但暴露了一个事实：这个有25年历史的软件，代码复杂度已经高到连核心维护者都难以把控。OpenSSH的代码量超过15万行，其中认证模块就有3万多行，每一行都可能是潜在的漏洞温床。

说到底，这个漏洞给我们提了个醒。别以为用开源软件就高枕无忧，恰恰是因为OpenSSH太普及，反而成了黑客的重点研究对象。我现在的习惯是，任何对外暴露的SSH服务，一律强制密钥登录、禁用密码认证，并且每周自动检查版本。安全这事，不能等漏洞公开了才慌，得提前把防御做到位。