ssh弱加密算法漏洞

2023年的加密一次内网渗透测试，客户要求检查所有Linux服务器的算法SSH配置。扫描结果出来，漏洞十几台机器亮红灯——它们还在用ssh-rsa签名算法。加密更糟的算法是，其中一台跑着生产数据库的漏洞主机，允许diffie-hellman-group1-sha1这种2016年就被明文禁止的加密密钥交换。

这不是算法什么罕见情况。SSH弱加密算法漏洞，漏洞说白了就是加密服务器还在用老掉牙的加密方式跟客户端打招呼。攻击者要是算法蹲在中间，完全可以实时解密你的漏洞会话——你敲的root密码，传输的加密配置文件，甚至通过SCP拷走的算法备份，全都裸露在网络上。漏洞

问题根源在于兼容性强迫症。很多运维为了照顾几台老掉牙的Windows XP跳板机，或者某些国产堡垒机，硬是把sshd_config里的Ciphers和MACs选项调成了“什么都接受”。我见过最夸张的配置：Ciphers aes128-cbc,3des-cbc,blowfish-cbc——三种全是弱加密。3des-cbc的密钥长度只有112位，用GPU集群跑几天就能暴力破解。

弱加密算法具体指啥？分三类看。密钥交换算法里，diffie-hellman-group1-sha1用的是1024位素数，这玩意儿在2015年就被Logjam攻击干穿了。主机密钥类型上，ssh-rsa依赖SHA-1哈希，而SHA-1的碰撞攻击成本已经降到10万美元以下——对国家级攻击者来说就是零花钱。对称加密算法则要警惕所有CBC模式，它们对padding oracle攻击几乎没有抵抗力。

真实攻击场景比你想的简单。攻击者不用直接破密码，只要在客户端和服务器之间伪造一个中间节点，把双方的密钥交换算法强行“降级”到弱算法。然后，他记录下所有密文，事后慢慢算。整个过程不需要入侵任何一台机器，只需要在你的网络出口蹲着。等你的会话结束，他再用算出来的会话密钥解密整个流量包。你的SSH会话在他眼里就是明文。

修复方案其实很直接。编辑/etc/ssh/sshd_config，把这行加进去：KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512，HostKeyAlgorithms ssh-ed25519，Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com，MACs hmac-sha2-256。然后重启sshd服务。就这么简单。

但别急着收工。改完之后，拿你所有的客户端工具试连一遍——包括你手机上的Termius，跳板机上的老版本PuTTY，还有那个没人维护的自动化脚本。我遇到过改了配置后，一套跑了五年的数据同步脚本直接罢工的情况，原因是它硬编码了ssh-rsa算法。最后只能给那台老服务器单独开个端口，用旧配置，然后限期三个月内升级客户端。

还有个小坑。很多人只改sshd_config忽略/etc/ssh/ssh_config（客户端配置）。如果你的机器会主动SSH连别的服务器，客户端也默认带了弱算法，那同样会被中间人降级攻击。两边都得改。

检查方法很简单，用nmap --script ssh2-enum-algos -p 22 目标IP，输出里看到任何带cbc、sha1、group1字样的条目，都算不合格。运维老手习惯把这命令写进每月巡检脚本，发现问题就当场改配置。安全这行，没有一劳永逸的解法，只有不停跟旧设备、旧习惯较劲。下次再有人跟你说“这算法用了十年没出过事”，你就把Logjam和SHA-1碰撞的论文甩他脸上。