18

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.

Improve this question

2 Answers 2

Reset to default
18

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.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \ mv /etc/ssh/moduli.strong /etc/ssh/moduli

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:

It is important that this file contains moduli of a range of bit lengths and that both ends of a connection share common moduli.

Which seems to argue against replacing existing moduli, though it doesn't really provide the actual reason for doing so.

Improve this answer
2
  • Related: Diffie-Hellman using a different modulus on both sides on Cryptography. To my limited understanding, it appears that if there are no shared moduli of a desired length, Diffie-Hellman with a group of that length is not possible in the general case, and might not be possible in any specific case. Hence, having moduli shared between the two endpoints is a mathematical requirement of the Diffie-Hellman key exchange protocol, and attempting to perform a Diffie-Hellman key exchange between two endpoints which have no common moduli will fail. Commented Jul 21, 2017 at 17:31
  • 5
    RFC 4419 [tools.ietf.org/html/rfc4419] is precisely for allowing the server to provide custom DH parameters. The server sends it's candidate parameters to the client, and if the client agrees, both sides use the server-provided parameters to generate a shared-secret which is used as the session key. So, it's perfectly fine if the server and client don't have the same entries in their moduli file. Commented Mar 6, 2018 at 21:10
3

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.

$ strace -e openat ssh user@localhost
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.