现在，DSA被OpenSSH弃用，后来将被完全删除：https ：//www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html
信息指出：
从OpenSSH 7.0版本开始，由于继承弱点，默认情况下在运行时禁用了ssh-dss密钥的支持。
如果您依靠这些密钥类型，则必须采取纠正措施
动作或风险被锁定。
最好的选择是使用诸如
rsa或ecdsa或ed25519之类的强大算法生成新密钥。 RSA密钥将为您提供与其他客户端/服务器的最大可移植性，而ed25519将为您提供OpenSSH的最佳安全性。
DSA密钥固有的弱点是什么？ ？
#1 楼
这是一个很好的问题。 OpenSSH的专用页面仅显示：OpenSSH 7.0和更高版本同样禁用ssh-dss（DSA）公钥算法。它也很弱，我们建议不要使用它。
它比公告中的“继承弱点”更详细。除了关于“最新发现”的一些未经证实的散布，我没有找到关于这些弱点的任何公开解释。因此，是时候进行一些侦查了。
在OpenSSH-6.9p1（Ubuntu 15.10软件包）的源代码中，对于密钥生成工具
ssh-keygen，我发现了这段引人注目的代码：>
maxbits = (type == KEY_DSA) ?
OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
if (*bitsp > maxbits)
fatal("key bits exceeds maximum %d", maxbits);
if (type == KEY_DSA && *bitsp != 1024)
fatal("DSA keys must be 1024 bits");
OPENSSL_DSA_MAX_MODULUS_BITS是OpenSSL标头中的常量，将其定义为10000。因此，前四行检查生成时请求的密钥大小是否可以实际处理密钥生成过程。但是，接下来的两行基本上说：“不管上面的测试如何，如果密钥是DSA并且大小不是1024，请注意。” 这6行本身就是一个确定的信号谁开发了该代码，就密钥大小而言并没有完全同意他自己。这段代码可能是增量地组装的，可能是由不同的人组装的。可以将“ 1024”的来源追溯到实际的DSA标准（称为“数字签名标准”的“ DSS”），即FIPS 186-4。该标准被多次修订。在第一个版本中，DSA被要求使用模数，其大小在512位和1024位之间（并且应为64的倍数，以简化实现者的工作）。后来的版本承认技术能力和数学上的进步，并且禁止除1024位以外的任何大小。现代版本的FIPS 186（第四版，截至2016年初）允许模数具有1024、2048或3072位的大小。
因此可以推测
ssh-keygen拒绝使用不同于1024位的模数大小，因为有人在某个时候阅读了当时规定的FIPS 186版本，并且没有人在修订FIPS标准时费心更新ssh-keygen。无论这种惊人的编程精神分裂症如何发展，原始结果是，当今使用的大多数DSA类型的SSH密钥（即使不是全部）都依赖于1024位模数。难题在于Logjam攻击。 Logjam基本上是在注意，当客户端和服务器同意使用弱加密时，它们可能会受到攻击。这是对SSL / TLS（而非SSH）的攻击。但是，Logjam文章并没有（正当）抨击为DH使用512位模数的SSL / TLS实现。它还为“州级对手”提供了一定的讨论空间。该部分主要说了一些已知的信息，即以1024位模为模的离散离散对数（可以同时破坏DH和DSA的东西）现在非常昂贵，但就我们目前对问题的了解而言，这并非不可能和可用的技术（类似于破坏RSA-1024，并且完全不同于破坏2048位DH或DSA，这对于当前的地球资源来说是不可行的。）
听起来像耳朵一样“天哪，我们都被国家安全局盗版了！”围绕Logjam问题的宣传（这是非常真实的）随之而来，涉及1024位DSA密钥（包括在SSH中使用它们时）的大量歇斯底里。
还有一点是，使用DSA需要为每个签名生成一个新的随机值，并且该值的生成质量至关重要。一些实施失败很严重，导致私钥泄漏（特别是对于某些“比特币钱包”）。 DSA的这一特性与其椭圆曲线版本ECDSA共享。它可以固定。但是，它灌输了DSA签名可能很难正确执行的想法（和ECDSA签名一样，但是椭圆曲线很酷，没有人希望禁止它们）。
这些参数加在一起说明了禁止。这可以看作是OpenSSH开发人员积极主动地采用安全性概念，并愿意强迫用户使用强密码的情况。另一种看待相同决定顺序的方式是，由于对FIPS 186的理解不佳，OpenSSH开发人员在某个时候犯了严重错误，然后试图以相当于将不便丈夫的尸体倾倒在海上的方式掩盖它。 />
请注意，破坏DSA密钥会使攻击者冒充您，但不能解密记录的会话。虽然可以说在某些时候切换到ECDSA密钥是一个好主意（这样可以节省一些带宽和CPU），但是没有密码分析的紧迫性。您仍然必须这样做，因为否则，您可能会因为某些打包程序对弃用策略过于热心而被锁定在服务器之外。
评论
另一个可能的解释是，有人对解决非主要领域的DLP问题感到震惊。 （尽管专家认为，这些攻击不能推广到实践中使用的主要领域。）
– CodesInChaos
17年4月8日在20:59
>>请注意，破坏DSA密钥会使攻击者冒充您，但不能解密记录的会话。 <<出于好奇，我应该记录一次从握手到结束的会话，一旦拥有私钥，是什么阻止了我解密该会话？
–已对偶
17年9月11日在10:46
@dualed SSH协议2使用Diffie-Hellman进行密钥交换。实际的会话密钥是由双方在会话开始时生成的，并且不会存储在本地或通过通信通道发送。知道私钥不会显示会话密钥。请参阅SSH如何同时使用RSA和Diffie-Hellman。
–贝恩
17-10-21在15:52
我一直很喜欢从源头挖掘出来的答案。它所揭示的内容远不止有关作者心态的文档！
–森林
17年12月21日，1：13
#2 楼
https://bugzilla.mindrot.org/show_bug.cgi?id=1647具有将DSA密钥限制为1024位的原因，但基本上：RFC4253第6.6节要求SHA1散列（160位）用于ssh-dss（即DSA）身份验证。FIPS 186-3第4.2节要求DSA密钥> 1024位才能使用比160位强的散列。
两者都只允许使用1024位密钥。
评论
186-3（和-4）4.2说“通常不应该”使用比L，N弱的哈希，而“应”定义为“强推荐而不是要求”。 4253还要求SHA1用于ssh-rsa（无论大小），但是OpenSSH在发布rfc8338的两年前实施了新的pkalgs rsa-sha2-256和rsa-sha2-512。
–dave_thompson_085
19-11-22在6:59
#3 楼
186-3（和-4）4.2说“通常不应该”使用弱于L，N的哈希值。
那部分说
A hash function that provides a lower security strength than the (L, N) pair ordinarily should not be used.
上面说的是
This Standard specifies the following choices for the pair L and N (the bit lengths of p and q, respectively): L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 Federal Government entities *shall* generate digital signatures using use one or more of these choices.
[编辑：我去读了NIST SP.800-57。秒5.6.1。即使允许违反FIPS 186-3中的建议并使用具有较大DSA密钥的SHA-1，它也不会变得更强大，因为它将仍然受到SHA-1的强度的限制。 >
OpenSSH在rfc8338发布前两年实施了新的pkalgs rsa-sha2-256和rsa-sha2-512
这是三年的标准草案
事实上，最初有一个dsa-sha2-256，它在符合FIPS 186-3的情况下允许2k和3k DSA密钥，但是很快就被丢弃了。这样的方案还需要软件升级。
评论
DSA密钥是否可能被视为重复项？不，不是真的重复。基本问题尚未回答。
如果您确实需要ssh的大型DSA密钥，则可以使用openssl生成具有不同位大小（例如2048或3072）的dsa密钥，然后使用ssh-keygen将其导入ssh。这是非标准的，但是openssh允许它作为客户端和服务器，而且我已经亲自验证了与openssh客户端和PuTTY作为客户端的互操作性，并与openssh作为服务器和dropbear作为服务器进行了对话。