On OpenSSH and Logjam
by Jethro Beekman – May 20, 2015 . Filed under: English, Technology, Security, SSH.
Recent work showing the feasibility of calculating discrete logarithms on large integers has put the Diffie-Hellman key exchange parameters we use every day in the spotlight. I have looked at what this means for SSH key exchange. In short, on your SSH server, do the following:
awk '{ if ($5 <= 2000) printf "#"; print }' /etc/ssh/moduli > /tmp/large_moduli
mv /tmp/large_moduli /etc/ssh/moduli
And put the following in your sshd_config:
KexAlgorithms [email protected],ecdh-sha2-nistp256,
ecdh-sha2-nistp384,ecdh-sha2-nistp521,
diffie-hellman-group14-sha1,
diffie-hellman-group-exchange-sha1,
diffie-hellman-group-exchange-sha256
Note that [email protected] is only supported in OpenSSH
6.5 and up, and only works reliably in
OpenSSH 6.7 and up. On your SSH
client, put the following in your ssh_config:
KexAlgorithms [email protected],ecdh-sha2-nistp256,
ecdh-sha2-nistp384,ecdh-sha2-nistp521,
diffie-hellman-group14-sha1
If with this configuration you are unable to connect to some SSH servers, and
you need to add diffie-hellman-group-exchange-sha1 or
diffie-hellman-group-exchange-sha256 to the supported list of algorithms, you
should recompile your SSH client with a DH_GRP_MIN of 2048, so that a server
can’t force your client to use a weak group.
Technical details
Now follows a detailed explanation of these recommendations. The following key exchange mechanisms are supported in the current version (6.8) of OpenSSH:
[email protected]ecdh-sha2-nistp256ecdh-sha2-nistp384ecdh-sha2-nistp521diffie-hellman-group1-sha1diffie-hellman-group14-sha1diffie-hellman-group-exchange-sha1diffie-hellman-group-exchange-sha256
The first four mechanisms, [email protected],
ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, do not use
prime-field Diffie-Hellman and are not affected. Previous
work
shows that these mechanisms are much faster when used at the same security
level, so you should use them!
The diffie-hellman-group1-sha1 mechanism uses the fixed 1024-bit Oakley
Group 2 (not the 768-bit group 1, as the
name of the mechanism might suggest). This group is within the range of being a
viable target for nation-state attackers, and should not be used.
The diffie-hellman-group14-sha1 mechanism uses the fixed 2048-bit Oakley
Group 14, which should be secure enough
for now.
The diffie-hellman-group-exchange-sha1 and
diffie-hellman-group-exchange-sha256 mechanisms let the client and server
negotiate a custom DH group. The client sends a tuple «min, n, max» to the
server, indicating the client’s minimum, preferred and maximum group size.
According to the RFC,
Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.
The OpenSSH server selects a suitable group from a pre-generated set of groups,
installed system-wide in /etc/ssh/moduli (falling back to /etc/ssh/primes),
using the choose_dh function in
dh.c. In case
no suitable group is found, the code defaults to Oakley Group 14, which is
safe. A pre-generated set is distributed with the OpenSSH
source and
many binary distributions and is infrequently changed. The group sizes
distributed with OpenSSH are 1024, 1536, 2048, 3072, 4096, 6144, and 8192 bits,
with about 30 groups per size. The OpenSSH-distributed 1024-bit groups are
well-known and within the range of being a viable target for nation-state
attackers, and as such should not be used.
It is possible to generate your own set of groups, in which case it would be
safer to use a 1024-bit group, but you might as well go for larger groups. The
ssh-keygen man page mentions that “It is important that … both ends of a
connection share common moduli.” That statement should not be interpreted as
“both server and client need to have the same moduli configured”, as the server
sends the chosen modulus to the client. As a case-in-point, the OpenSSH client
does not access the system-wide moduli file at all during connection setup.
Speaking about the client, it usually offers the RFC-specified minimum of 1024 bits. There is nothing preventing a server from using that value and offering a well-known (and thus weak) group. So, a standard client shouldn’t use the custom group key exchange mechanisms, unless there is a way to change the minimum group size.