将自定义 SSH DH 组部署到仅客户端系统是否有任何安全优势?

use*_*ser 17 ssh ssh-keys logjam

针对SSH 上与Logjam相关的攻击的一种建议的缓解策略是使用类似的东西生成自定义 SSH Diffie-Hellman 组(以下针对 OpenSSH)

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Run Code Online (Sandbox Code Playgroud)

然后用输出文件替换系统范围的模文件moduli-2048。(ssh-keygen -G用于生成候选 DH-GEX 素数,并ssh-keygen -T测试生成的候选者的安全性。)

这显然是在 SSH 服务器上做的一个合理的事情,否则将使用众所周知的组,这些组很适合预先计算,但是将自定义 SSH DH 组部署到仅客户端系统上是否有任何安全优势?(也就是说,系统连接到 SSH 服务器,但本身从不充当 SSH 服务器。)

我主要对与 Linux 上的 OpenSSH 相关的答案感兴趣,但更通用的答案也将不胜感激。

Mic*_*ton 19

如果你真的想要,你可以,但我不会费心为 OpenSSH 重新生成 2048 位 DH 参数。您需要更多重要的事情来保护 SSH,例如禁用弱加密

做的是删除现有的这低于2048位。

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli
Run Code Online (Sandbox Code Playgroud)

如果您没有注意到,OpenSSH 附带了大量预先生成的模块,最高可达 8192 位。虽然我们今天肯定担心 1024 位素数,但相信 2048 位素数在可预见的未来是安全的。虽然这最终会改变,但可能是下周,但更有可能在我们成为养老金领取者之后很久......

ssh-keygen手册页中还有一个奇怪的地方:

该文件包含一系列位长度的模数并且连接的两端共享公共模数,这一点很重要。

这似乎反对替换现有的模块,尽管它并没有真正提供这样做的实际原因。

  • RFC 4419 [https://tools.ietf.org/html/rfc4419] 正是为了允许服务器提供自定义 DH 参数。服务器将它的候选参数发送给客户端,如果客户端同意,双方使用服务器提供的参数生成一个共享秘密作为会话密钥。因此,如果服务器和客户端在它们的模文件中没有相同的条目,那完全没问题。 (5认同)