SSH using only strong key exchange algorithms

Support
1

Hi,

As I was looking for a backup solution, I ran into Duplicati, which seems really nice and user friendly. However, when I want to connect to my remote server using SSH (SFTP), I get the following error message:

Failed to connect: Failed to negotiate key exchange algorithm.

My servers are configured to use only strong cipher suits and key exchange algorithms. I appears Duplicati is not prepared to support the strongest key exchange algorithms.

Is there an easy way this could be modified.

I do understand you want to serve as many people as possible and therefor might consider supporting the weaker key exchange algorithms but as a security junkie I would like to see support for strong key exchange algorithms as well.

Thank you!

2

Don’t know the details but if duplicati doesn’t support your keys, try using the rclone backend and see if that supports your keys.

3

Thanks a lot Wim, I will try to that for sure! :slight_smile:

4

Can you list your cipher suite configuration? I’ll try replicating your issue…

5

Hi, of course!

As a new user I am limited to the amount of links in a post. Since the key exchange algorithms uses the @ sign it thinks I am sending a lot of links in a post.

Please have a look at the following URL:

Lines 8 through 13 is what you could use to replicate the issue.

Thank you!

6

Perfect, I’ll try them out with Duplicati when I get a chance.
I was comparing to my own SSH server settings and am curious why you do not have the following:

ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group-exchange-sha256

I removed what I thought were less secure kex algorithms a while back but I still have those 4… you probably know something I do not.

Edit to add: also what about this MAC? hmac-sha2-256

Thanks!

7

I haven’t tried it with Duplicati myself yet, but it does seem like your KEX and MAC choices have no matches with what is available in the SSH library that Duplicati uses:

Wonder if it would work if you enabled this KEX: diffie-hellman-group-exchange-sha256 and this MAC: hmac-sha2-256 (or hmac-sha2-512)

But per my previous message I am not sure if there are vulnerabilities with any of those. (I know to avoid MD5 and SHA1 stuff…)

8

We’re definitely starting to feel the pressure of SSH.NET as a dependency :sweat_smile:

It doesn’t handle the new SSH key formats produces on newer Linux machines either.

9

Hi,

I haven’t had the chance to test these just yet. However, I will try to this in a little while and report back.

I use the following script in order to test for weaknesses in KEX, MAC etc.:

10

image
image.png946×834 158 KB

This is the result when adding ecdh-sha2-nistpXXXX as a KEX

11

And this is the result with my configuration:

image
image.png875×586 100 KB

12

Very interesting, I’m going to check out that script later.
What does it say for MAC hmac-sha2-256 and hmac-sha2-512 ?

Because of SSH library limitations, you may have to enable one of those MAC protocols as well as KEX diffie-hellman-group-exchange-sha256. It seems the script you are using warns you about that KEX because it does not indicate a specific modulus bit size - which is true - so there is some theoretical risk there. But with my googling I found no indication that the KEX itself is somehow flawed/broken.

Alternatively you could use a different protocol with Duplicati.

13

This article has an interesting thought about diffie-hellman-group-exchange-sha256…
https://stribika.github.io/2015/01/04/secure-secure-shell.html

It says if you choose to enable it, you can ensure that larger bit size modulus is used by deleting ones with less than 2000 bits from your /etc/ssh/moduli file.

This may be a way to mitigate the reason this KEX is flagged with a warning…

14

Actually looks like removing smaller moduli is not even needed if you are using a relatively modern OpenSSH server.

https://www.openssh.com/releasenotes.html

OpenSSH 7.2/7.2p1 (2016-02-29)

 * ssh(1), sshd(8): increase the minimum modulus size supported for
   diffie-hellman-group-exchange to 2048 bits.

So… I’m thinking that “warning” can be dismissed.

15

It has an issues tracker. Feel free to add your comments, but I don’t see much recent code change activity. Duplicati at least keeps changing code even though the issues list sometimes seems to have no bottom… Duplicati’s lead author did do AES in C#, but I don’t know if he or anyone else here can add new KEX code.

No secure HMAC algorithms offered for SSH/SFTP seemed to say that obviously the library gets replaced, however it offers no specific suggestions for something compatible with open source. I’m not finding much.

Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) is an effort to update IETF (Internet Engineering Task Force – a.k.a. the global standards body for such things) advice about KEX algorithms. Interestingly, they still recommend diffie-hellman-group14-sha1 (for now, due to availability problems for better algorithms) and so does SSH.COM. So that might be the best of what SSH.NET can do.

Probably your perspective also varies depending on whether you’re a server who has to let popular clients connect somehow (or suffer complaints) or someone seeking a client which is ahead of the broader pack.

SSH implementation comparison tries to track who has what, though I don’t know how current the data is.

I haven’t verified it, but I think what Duplicati has is limited to the below, though note others are comments:

https://github.com/sshnet/SSH.NET/blob/bd01d971790a7c1fa73bad35b79ada90bf69e62d/src/Renci.SshNet/ConnectionInfo.cs#L323

By comparison, I think rclone uses the following, and this looks like it knows (maybe even supports) more:

https://github.com/golang/crypto/blob/4def268fd1a49955bfb3dda92fe3db4f924f2285/ssh/kex.go#L22

17

Currently,

  • RSA is still recommended as a gold standard (strong, wide compatible)
  • ed25519 is good (independent of NIST, but not compatible with all old clients).

Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones.

Frankly, for you, as an end user, it should not matter. Some of the keys might have some security concerns, but none of them is considered completely broken with reasonable lengths, which could possibly cause man-in-the-middle attack or something similar.

The article mentions “severe vulnerabilites”, but not saying anything specific. If it had such serve vulnerability, nobody would use it, support it, nor recommend it. Without any reference, it is pretty hard to comment on your concerns.

18

Oh for me as an end user it does matter. I’m a security consultant and fully understand the hardening process of a server. I will not ever use weak mechanisms in order to use a tool or program.

If this backup system is not capable of supporting newer key exchange algorithms, I will simply not use it, which is a shame because I do like it.

19

Check if rclone supports your key exchange, and configure that for your backend.

20

Why not use diffie-hellman-group-exchange-sha256? As I noted above, the script you run flagged it with a warning because modulus size is not fixed - BUT - OpenSSH was configured to use minimum 2048 bit over 3 years ago.

21

This might become more and more the alternative to better security. Possibly I found its kex algorithms:

x/crypto/ssh: Support sha-2 family hash algorithms for key exchange (RFC 8268) #31731 is trying to add several others from your list to the Go crypto lib that rclone uses (I think) but getting some pushback on it.

Duplicati’s C# lib is SSH.NET and is getting less attention. No updates in a year – any good alternatives?
Support newer SSH Ciphers and MACs #53 asks for curve25519-sha256@libssh.org (among others).