SSH协议是远程服务器管理中核心的密码协议，也可能是除了SSL/TLS协议之外应用最为广泛的密码协议。不过，在各种关于SSH协议的“安全加固指南”、“安全配置说明”文档中，我们鲜有见到关于SSH所使用的公钥私钥本身的安全分析指南，最多就是提示大家不要使用RSA-512或者1024这种安全性不足的密钥。这其中主要的原因可能在于收集到SSH公钥登录相关的密钥凭据这件事比较困难。
在2025年的CCS计算机安全会议上，一项获得了杰出论文奖的研究工作 Onthe Security of SSH Client Signatures 利用了互联网上可以搜索到的各类公钥信息，开展了全面的SSH密钥安全分析，还顺带分析了各种SSH客户端软件在生成和使用公私钥时候是否存在安全检查不严格的问题：
首先，我们需要了解一下SSH协议中的公私钥使用：在SSH协议中，除了基于口令（password）的认证方式，最基本的认证方式就是基于公私钥的认证。这种认证在现实中广泛应用于系统管理员和用户远程登录服务器：通过预先将公钥在服务器端注册（例如存储于authorized_keys文件中），用户在登录时只需要使用私钥来完成一系列的挑战-响应过程即可登录，这个过程并不会暴露和传输私钥本身，而且基本上不需要人工干预（除非设置了用于私钥保护的passphrase），因此安全性比传统的口令登录方式要好很多。
正因为如此，除了网络服务器之外，像GitHub这样的源码管理网站，也都支持使用公私钥认证的方式来验证用户身份。这也使得大规模收集SSH相关公私钥数据并进行分析成为可能。本文作者主要从如下三个平台去收集相关的公钥：
GitHub
GitLab
Launchpad
作者总共进行了两次SSH公钥的数据集收集，第一次是2023年，第二次是2025年，总体的情况如上表所示。我们看到，目前使用的这些SSH公钥基本就只有四大类：RSA、Ed25519（EdDSA）、ECDSA和DSA，其中DSA的使用比例是非常少的，而占了大头的是RSA和Ed25519这两类，而且从时间上看，RSA公私钥从早期占绝对多数比例，到2025年逐渐被Ed25519蚕食了很多份额，RSA算法那冗长低效的实现应该难辞其咎。
作者总共在2023年的数据集中发现了77411个RSA key，使用的模数（n）小于2048比特，注意到NIST是在2010年左右就推荐大家放弃RSA 1024而转向RSA 2048，而且后面是直接要求大家停用RSA 1024，但是目前仍然还有许多在使用的RSA公钥使用了此类“弱”密钥，其中还有93个密钥的模数小于830比特（目前公开的RSA分解世界记录，2020年完成）。除此之外，还有一些比较奇怪的现象，比如有20240个密钥的模数不能被8整除（大部分是1023或2047比特），可能造成兼容性问题。
而到了2025年，数据集中竟然仍然还有77438个使用的模数小于2048比特的RSA公钥（比2023年不降反升了），而且模数小于830的RSA公钥也还有98个，作者于是比较了一下2023年和2025年的数据集中共享的弱密钥，发现在两个数据中都存在的模数小于2048比特的RSA公钥有60493个，模数小于830的RSA公钥有90个，看来大家并不会知错就改（或者是没人提醒大家纠正错误？）和2023年数据集相比，2025年数据集中出现了一些独特的奇怪RSA公钥：有4个公钥使用的加密指数e居然是偶数，其中三个e是65538（2的16次方加2，正常情况下是65537）。
针对RSA有一个共享素因子攻击，就是说如果不同的公钥使用了共享的素因子（例如n1=p1q1，n2=p1q2），那么就只需要执行一个简单的欧几里得算法（GCD）就可以找到这个共享的素因子。这几年很多研究工作都在做这种分析，而且有一个很有趣的Batch GCD算法（大名鼎鼎的DJB设计的）能够快速分析一大批公钥的共享素因子情况。在2023年的数据集中，作者发现有305个公钥存在共享素因子情况（因此可以被分解），而其中的249个公钥的共享素因子比较小（最大的也不过1842374275），可能是生成的时候出错了，但是其中56个公钥的素因子就是正常的大素数，因此这56个公钥对应的私钥就彻底被破解了。到了2025年，已经不存在类似这56个出问题的公钥这种“使用了共同的大素数因子”的问题，只有128个公钥存在小的素数因子（最大不过1300062075）。
接下来作者继续分析了DSA和ECDSA的公钥情况，发现在两个数据集中存在相同的6个公钥的p长度小于795比特（都是在launchpad上找到的），而在launchpad上作者还找到了一个1024比特的DSA公钥，它的p甚至不是素数，g和y的阶也不是q，估计这个公钥就是错的。而对应地，在2023年的数据集中，有642个EdDSA的公钥格式不正确，到了2025年这个数字增加到了1400个。
分析完了公钥的问题，作者接下来考虑了另一个问题，如果公私钥本身出了问题（不管是出于什么原因，比如可能在传输过程中被人修改），现在的系统（服务器和客户端）能不能检查发现呢？为了回答这个问题，作者首先调查了GitHub、GitLab和Launchpad这三家代码托管网站的情况，结果发现，很多有问题的公钥格式依然可以正常上传到这些网站并且被使用，而Launchpad是检查最宽松的：
作者还对大家广泛使用的SSH客户端（client）和代理（agent）进行了调查，统计了它们的特征：
在这些软件中，作者找到的最严重的问题就是PuTTY 高危漏洞 CVE-2024-31497，这个问题实际上在2024年就由国内的公众号G.O.S.S.I.P报道过（G.O.S.S.I.P 安全事件 2024-04-16 PuTTY 高危漏洞 CVE-2024-31497），同时G.O.S.S.I.P还有一个关于这个漏洞分析的挑战：【G.O.S.S.I.P 智力挑战 2024-04-20 大破PuTTY】。关于漏洞的具体攻击，大家可以参考 https://github.com/HugoBond/CVE-2024-31497-POC 这个Proof-of-Concept exploit~
论文：https://arxiv.org/pdf/2509.09331v1
代码：https://zenodo.org/records/17253724
声明：本文来自华东师范大学密码学院，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
