How can ssh-keygen be used to update /etc/ssh/moduli?

Question

I have some machines whose primes in /etc/ssh/moduli are now considered too weak because they are less than 2048 bits. There are a couple questions on this site concerning the consequences of updating /etc/ssh/moduli:

• Does changing /etc/ssh/moduli impact previously generated keys?
• https://security.stackexchange.com/a/41947/145516

But neither of these discuss the mechanics of actually updating the file (understandably since those questions focus on what happens after the file is updated, not how to actually update the file). Considering the importance of this, I want to make sure I update the file correctly. Here are a couple of links describing how to run ssh-keygen to generate primes for a couple Linux flavors:

• Ubuntu: http://manpages.ubuntu.com/manpages/jammy/en/man1/ssh-keygen.1.html#moduli%20generation
• RHEL: https://www.redhat.com/en/blog/primes-parameters-and-moduli (See the section ** Generating primes in advance**.

Using either of those methods, as appropriate for the OS, can I then simply copy the resulting file down on top of /etc/ssh/moduli?

Thus, to be explicit, I intend to do the following for my RHEL 7 system:

ssh-keygen -G candidates -b 2048
ssh-keygen -T moduli -f candidates
sudo cp candidates /etc/ssh/moduli

My first question: can someone confirm whether this is correct? If, broadly speaking, that is correct, how can I interpret the ssh-keygen output of those two commands to see whether they are succeeding or not. I'm cautious because the output of that second ssh-keygen -T test execution outputs this:

$ ssh-keygen -T moduli -f candidates
Wed Apr 27 15:02:51 2022 Found 33 safe primes of 46769 candidates in 224 seconds

I do not know how to interpret this output, and the man page for -T simply says Test DH group exchange candidate primes (generated using the -G option) for safety with no further information on how to interpret the output. So that leaves me with the following follow-up questions to the first one:

• When my output says that it found "33 safe primes", does that mean I should filter the file for those 33 "safe" primes and not use the other candidates in the file somehow? Or is the output an indication that the file "passes" its inspection and the file is thus "safe"?
• What output should I expect from this test run if the file is deficient in some way? I assume since it is a "test" run that the file generated from ssh-keygen -G can fail somehow.
• For these commands, can I ignore the output and simply rely upon 0 exit codes from these commands to communicate to me that there were no problems in generating or testing the file?

Answer 1

I intend to do the following for my RHEL 7 system:
ssh-keygen -G candidates -b 2048
ssh-keygen -T moduli -f candidates
sudo cp candidates /etc/ssh/moduli

NO! The output from -T is moduli; that is the file you should use. The entries in candidates have not been screened and are mostly inadequate and very dangerous.

(Also a note: OpenSSH versions 8.2 (2020-02) up no longer use -G and -T, it's now -M generate and -M screen. But RedHat 7 is older than that.)

When my output says that it found "33 safe primes", does that mean I should filter the file for those 33 "safe" primes and not use the other candidates in the file somehow? Or is the output an indication that the file "passes" its inspection and the file is thus "safe"?

No. It means there were 46769 entries in the input candidates of which only 33 passed screening and were written to moduli. The entries in moduli are good and should be used (if you want DHGEX at all, see below). The remaining entries in candidates that were not copied to moduli MUST NOT be used.

The references to 'safe[ty]' are incomplete and somewhat misleading. 'Safe primes' are of the form p = 2q + 1 with q also prime, but this terminology is a relic: for the prime sizes used in the very early days of public-key cryptography (about 1980) using this form did impede one attack, but for the sizes used today the prime form no longer matters. However, this form does make it easy to ensure the full-group order (p-1) is nonsmooth and to find a generator of an order-q subgroup, which are still vital. What actually happens is:

• -G uses a sieve to generate large numbers that are potentially prime

• -T uses Miller-Rabin to test whether those potential primes are actually primes and safe primes (technically 'probable' primes, although in cryptospeak 'probable' means 'so nearly certain you can ignore the difference')

These are useful only in combination, and it's not entirely clear why they are provided as separate operations you must combine. I suspect it's because the software that became OpenSSH was designed in the days when CPUs were only a few MHz and you couldn't afford to put large memories on most of them; -G requires lots of memory (at least by 1990s standards) but little CPU and is sequential, while -T requires lots of CPU but almost no memory and can be massively parallel, so you could run -G on your one 'big' system and then farm out pieces of the candidates file to multiple systems to run -T in parallel, and perhaps it would take only hours instead of weeks.

What output should I expect from this test run if the file is deficient in some way? I assume since it is a "test" run that the file generated from ssh-keygen -G can fail somehow.

As above, most of the entries output from -G are not actually prime (or safe) and thus 'deficient'; that's why you need -T.

For these commands, can I ignore the output and simply rely upon 0 exit codes from these commands to communicate to me that there were no problems in generating or testing the file?

I'm not sure. OpenSSL isn't very rigorous about setting exit status. However, if the second output file (the one from -T) is created and nonempty, you can trust its contents. And if it doesn't exist or is empty and you try to use it, you will immediately get failures.

But do you need to? If the devices connecting to your server are reasonably modern (and certainly if they are using OpenSSH client) they won't use classic/modp DH (now somewhat clumsily retronymed FFDH, Finite Field DH) at all, they will use elliptic-curve forms: either X9 ECDH with P256, P384, or P521, or Bernstein et al's XDH25519. This makes your ever-so-tenderly created moduli utterly useless. Even if you have ancient or defective clients, if they support FFDH 2k at all they probably support DH-group14, so you can enable that and disable DH-group-exchange aka DHGEX and still not need moduli at all.

Compare Is it considered worth it to replace OpenSSH's moduli file?
and How to create most secure SSH keys and D-H moduli on standard Linux PC?