I was reading https://weakdh.org/sysadmin.html
They also have a very interesting paper as a PDF.
Anyway it appears that most ssh servers, when using DHE key exchange, use the 1024-bit Oakley Group 2 and there is suspicion the NSA has done the pre-computations needed to passively decrypt any tls communication using DHE with that particular prime group.
They recommend setting the following:
KexAlgorithms curve25519-sha256@libssh.org
I don't even see that directive in my sshd config to set it, I suppose it may be one that is manually added when needed but I want to verify it actually means something in CentOS 7 ssh.
Also I'm a little worried that maybe curve25519 is one of the curves that Red Hat (and thus CentOS 7) doesn't support due to patent concerns.
If it is, is there a suggestion on what curve should be used instead?
On 09/11/2015 11:35 AM, Alice Wonder wrote:
I was reading https://weakdh.org/sysadmin.html
They also have a very interesting paper as a PDF.
Anyway it appears that most ssh servers, when using DHE key exchange, use the 1024-bit Oakley Group 2 and there is suspicion the NSA has done the pre-computations needed to passively decrypt any tls communication using DHE with that particular prime group.
They recommend setting the following:
KexAlgorithms curve25519-sha256@libssh.org
I don't even see that directive in my sshd config to set it, I suppose it may be one that is manually added when needed but I want to verify it actually means something in CentOS 7 ssh.
Also I'm a little worried that maybe curve25519 is one of the curves that Red Hat (and thus CentOS 7) doesn't support due to patent concerns.
There are no patent concerns with Dan's c25519. But its acceptance by the standards communities is new. Like really summer 2014 at the Toronto IETF. Typical Dan presentation...
It HAS been around for some time and has been extensively reviewed. The code is really clean and easy to review and implement, even in highly constrained devices.
If it is, is there a suggestion on what curve should be used instead?
Once upon a time, Alice Wonder alice@domblogger.net said:
They recommend setting the following:
KexAlgorithms curve25519-sha256@libssh.org
I don't even see that directive in my sshd config to set it, I suppose it may be one that is manually added when needed but I want to verify it actually means something in CentOS 7 ssh.
Also I'm a little worried that maybe curve25519 is one of the curves that Red Hat (and thus CentOS 7) doesn't support due to patent concerns.
That is supported in the CentOS 7 version of OpenSSH. Look at the man page for sshd_config and you'll see the KexAlgorithms option listed and its valid values. You can always see what your exact copy and config of OpenSSH are using by running "sshd -T".
However, if you set it as above, you would _only_ be able to connect with that algorithm, and not all SSH clients support that (even for example OpenSSH on CentOS 6).
On 09/11/2015 08:44 AM, Chris Adams wrote:
Once upon a time, Alice Wonder alice@domblogger.net said:
They recommend setting the following:
KexAlgorithms curve25519-sha256@libssh.org
I don't even see that directive in my sshd config to set it, I suppose it may be one that is manually added when needed but I want to verify it actually means something in CentOS 7 ssh.
Also I'm a little worried that maybe curve25519 is one of the curves that Red Hat (and thus CentOS 7) doesn't support due to patent concerns.
That is supported in the CentOS 7 version of OpenSSH. Look at the man page for sshd_config and you'll see the KexAlgorithms option listed and its valid values. You can always see what your exact copy and config of OpenSSH are using by running "sshd -T".
However, if you set it as above, you would _only_ be able to connect with that algorithm, and not all SSH clients support that (even for example OpenSSH on CentOS 6).
Thanks - what I ended up doing is:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Then I generated fresh 2048 and 4096 primes for the moduli file.
So far it seems all the ssh clients I have tried work.
-
Alice Wonder -
Chris Adams -
Robert Moskowitz