One suggested mitigative strategy against Logjam-related attacks on SSH is to generate custom SSH Diffie-Hellman groups using something like (the below being for OpenSSH)
ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
followed by replacing the system-wide moduli file with the output file moduli-2048
. (ssh-keygen -G
is used to generate candidate DH-GEX primes, and ssh-keygen -T
to test the generated candidates for safety.)
This is pretty clearly a reasonable thing to do on SSH servers that otherwise would be using well-known groups that lend themselves well to precomputation, but are there any security benefits to deploying custom SSH DH groups onto client-only systems? (That is, systems that connect to SSH servers, but never act as an SSH server themselves.)
I am primarily interested in answers relating to OpenSSH on Linux, but more generic answers would be appreciated as well.
You can if you really want, but I wouldn't bother regenerating 2048-bit DH parameters for OpenSSH. There are much more important things you need to do to secure SSH, like disabling weak crypto.
What I would do is delete the existing ones which are less than 2048 bits.
In case you hadn't noticed, OpenSSH ships with a large number of pre-generated moduli, all the way up to 8192 bits. While we're certainly concerned about 1024-bit primes today, 2048-bit ones are believed to be safe for the foreseeable future. And while that will eventually change, it could be next week, but it's more likely to be long after we've become pensioners...
There is also this curious bit in the
ssh-keygen
man page:Which seems to argue against replacing existing moduli, though it doesn't really provide the actual reason for doing so.
The answer is: No. There are no benefits. :)
/etc/ssh/moduli
file is only used for the server-side.You don't need to worry about that file for the SSH client-side:
You can trace the execution of SSH client and check that it does not open that file.