openssh用户枚举漏洞

OpenSSH 在默认配置下会泄露用户名是户枚否存在。这不是举漏猜测，是户枚实测结果。你拿一个用户名去连服务器，举漏如果用户不存在，户枚服务端在密钥交换完成后立刻断开；如果用户存在，举漏它会继续走认证流程，户枚让你输入密码或尝试公钥。举漏响应时间差通常在几十毫秒到几百毫秒之间，户枚脚本一跑，举漏批量枚举。户枚

这个问题的举漏根源在 SSH 协议本身。RFC 4252 定义了认证流程，户枚但没强制要求服务端对"用户不存在"和"认证失败"返回完全一致的举漏响应。OpenSSH 的户枚实现选择了实用主义路线：用户不存在就直接踢掉，省得浪费资源。安全圈的人早就知道这事，2006 年就有工具 ssh-user-enum 专门干这个。后来 Nmap 的 ssh-auth-methods 脚本也带了这个能力，一条命令就能扫出一堆有效用户名。

我去年做内网渗透测试时碰到过一台 CentOS 7 的机器，OpenSSH 7.4。用 Metasploit 的 ssh_enumusers 模块跑了一遍，三千个常见用户名里筛出十七个有效的。耗时不到四分钟。管理员后来跟我说，他以为改了 SSH 端口、禁了 root 登录就安全了。端口改到 22222 确实挡住了扫描器，但挡不住针对性的枚举。攻击者只要知道 IP，换个端口一样连。

漏洞的利用门槛低得离谱。Python 写个脚本，用 paramiko 库循环尝试，捕获 AuthenticationException 和 SSHException 的区别就能判断。更粗糙的办法是直接看连接被重置的时间：用户不存在时，服务端发完 SSH_MSG_DISCONNECT 就关连接，比正常认证失败快一截。时间差攻击在这个场景下意外地好用。

OpenSSH 官方对这个问题的态度一直很暧昧。邮件列表里有人提过要统一响应，但维护者认为这会增加认证阶段的资源消耗，而且枚举本身需要大量连接，日志里全是失败记录，容易发现。这个逻辑站不住脚——攻击者可以慢速枚举，每分钟试一个用户名，日志里根本看不出异常。我见过一个案例，攻击者用三个月时间枚举了某高校的 SSH 用户，每天只试二十个，管理员完全没察觉。

缓解手段倒是有几个。最直接的是 MaxStartups 调低，限制并发未认证连接数。但治标不治本，慢速枚举照样绕。Fail2ban 能挡暴力破解，对枚举效果有限，因为枚举的连接往往不触发密码失败计数。真正有效的是改认证方式：只允许公钥认证，关掉密码认证。用户不存在时，服务端直接拒绝密钥交换，攻击者连时间差都测不到。代价是管理麻烦，新用户加公钥得走流程。

另一个思路是端口敲门或者用 VPN 限制访问源。这属于网络层防护，跟 SSH 本身没关系了。我个人的习惯是：对公网暴露的 SSH，一律只开公钥认证，密码认证彻底关掉。内网机器可以宽松点，但至少把 PermitRootLogin 设成 no，再装个 sshguard 之类的工具盯着日志。

说回漏洞本身。CVE 编号我没记错的话是 CVE-2018-15473，影响 OpenSSH 7.7 之前的版本。7.7 之后官方加了个补丁，让认证失败和用户不存在的响应时间更接近。但补丁不完美，某些配置下还是能测出差异。安全研究圈子里有人发过论文，用机器学习分析响应时间分布，准确率能到百分之九十以上。所以别指望版本升级能彻底解决，这本质上是协议设计遗留问题。

最后提一句：如果你在跑 SSH 服务，现在就可以拿 ssh -o PreferredAuthentications=none invaliduser@yourhost 试试。看返回的 Permission denied 和 Connection closed by authenticating user 有什么区别。有区别就说明你也在受影响范围内。别等扫描器找上门才动手。