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.
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.
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.
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.
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.
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.