20

Consequences of tampered /etc/ssh/moduli describes a possible risk if the moduli file for an OpenSSH server has been tampered with.

Taking the logic a step further, is there any concern with the default file shipped with OpenSSH? I ask because the Secure Secure Shell article mentions this:

If you chose to enable 5 [diffie-hellman-group-exchange-sha256], open /etc/ssh/moduli if exists, and delete lines where the 5th column is less than 2000. If it does not exist, create it:

ssh-keygen -G "${HOME}/moduli" -b 4096
ssh-keygen -T /etc/ssh/moduli -f "${HOME}/moduli"
rm "${HOME}/moduli"

This reads to me as though DH primes less than 2048 are considered insecure, and should be replaced with larger primes. However, the OpenSSH developers, smart people, haven't replaced the file that ships by default with one that does include larger primes. Am I missing something?

Community
  • 1
evaryont
  • 345
  • 1
  • 2
  • 6
  • It does include large primes, but I'm guessing that smaller ones have not been replaced for compatibility with old servers that aren't upgraded. – RoraΖ Jan 15 '15 at 12:47
  • Additional infos on the topic https://www.linode.com/docs/security/advanced-ssh-server-security/ – intika Jul 15 '20 at 01:25

2 Answers2

17

Exchange/Selection process

Why remove primes shorter than 2000 bits? According to RFC4419, the key exchange starts with the client sending its preferences to the server in the form of 3 numbers:

  • the minimum acceptable modulus length,
  • the maximum acceptable length
  • and the preferred length.

Then the server chooses a random prime that best satisfies this requirement.

In practice (at least with OpenSSH 6.7), the client's minimum and maximum is always 1024 and 8192. The preferred length is 8 times the security level of the symmetric cipher. The server then chooses like this:

  • it discards the primes outside the min-max range,
  • then it picks the shortest available length that's not less than the preferred length
  • finally, it chooses one randomly out of those.

With AES-128, we end up with an 1024 bit modulus which is more like 2^80 effort to break. (It's not linear, you can't just multiply by 8.)

Why regenerate?

Why regenerate the file from scratch? To quote RFC4419:

The use of multiple moduli inhibits a determined attacker from
precalculating moduli exchange values, and discourages dedication of
resources for analysis of any particular modulus.

This has been demonstrated in the Logjam attack.

It is not as effective if everyone uses the same moduli file distributed with the SSH package. For this reason, I generated different moduli files on every host.

Note: modern SSH uses elliptic-curve Diffie-Hellman, which is more secure in theory.

If you want to generate new non elliptic-curve primes do this:

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

Then replace the contents of your moduli (usually /etc/ssh/moduli) file with the contents of moduli-2048

Community
  • 1
stribika
  • 336
  • 2
  • 4
  • Sorry to do a necro, but does your statement _"modern SSH uses elliptic-curve Diffie-Hellman"_ mean that I no longer need to generate new moduli using the `ssh-keygen -G` and `ssh-keygen -T` procedure? – pepoluan Aug 01 '16 at 12:15
  • 1
    If you disable all the DH-GEX algorithms on the server, then you don't need it. Otherwise clients may still try to use it, and if you don't have a file at all (or there are no valid choices), the server will send the hardcoded Group 14, Group 16, or Group 18. – stribika Dec 30 '16 at 01:42
7

The ssh-keygen options -G and -T seem to be obsolete.

According to man ssh-keygen, in the MODULI GENERATION section, the current commands are:

ssh-keygen -M generate -O bits=2048 moduli-2048.candidates
ssh-keygen -M screen -f moduli-2048.candidates moduli-2048
cobbzilla
  • 171
  • 1
  • 2