17

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.

user
  • 4,267
  • 4
  • 32
  • 70

2 Answers2

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Related: [Diffie-Hellman using a different modulus on both sides](https://crypto.stackexchange.com/q/30424/1142) on [crypto.se]. 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. – user Jul 21 '17 at 17:31
  • 5
    RFC 4419 [https://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. – Brian Minton Mar 06 '18 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
Adi Roiban
  • 793
  • 3
  • 7
  • 12