Release 2.0.6.1 (beta) 2021 - SFTP failure (Synology)

I think that’s still possible, but debugging this way can in general be much more difficult. The releases are built in release mode where the compiler can optimized the code in a way where what you see in the source code doesn’t quite reflect what is being run. As such, you might find that you won’t be able to set a breakpoint on certain lines, methods can get inlined, etc.

Nice find @drwtsn32! Looks like with my setup I’m getting a ed25519 host key.

Limit what algorithms or ciphers are used #730 might be a way out, if it can trim things down on mono.

Maybe it’s possible to configure the SSH.NET client to not advertise support for ecdsa host keys when running under mono?

Look above your post.

Ah that makes sense… I wasn’t sure why I had a different result.

I don’t normally use Bitvise and after install it only had those two keys. ECDSA and the RSA one.

I didn’t see that post, but I had a tab open with that issue!

@drwtsn32, is it easy for you to try this patch (with your ecdsa key added back) to see if this approach might work?

diff --git a/Duplicati/Library/Backend/SSHv2/SSHv2Backend.cs b/Duplicati/Library/Backend/SSHv2/SSHv2Backend.cs
index 61241914d..92c6508b7 100644
--- a/Duplicati/Library/Backend/SSHv2/SSHv2Backend.cs
+++ b/Duplicati/Library/Backend/SSHv2/SSHv2Backend.cs
@@ -328,6 +328,7 @@ namespace Duplicati.Library.Backend
             if (m_keepaliveinterval.Ticks != 0)
                 con.KeepAliveInterval = m_keepaliveinterval;
 
+            con.ConnectionInfo.HostKeyAlgorithms.Remove("ecdsa-sha2-nistp384");
             con.Connect();
 
             m_con = con;
1 Like

Yes I’ll give it a try tonight and let you know!

BTW, here are where the host key strings are defined:

Also, there is an issue with how SSH.NET implements this, where the order in which the keys are enumerated is not guaranteed. I bumped it in December, but it hasn’t gotten much attention.

1 Like

2020.0.0 names the new key exchange (where mine was dying) and host key algorithms, but the file you cite also shows them, and its blame view shows when they were added. Knowing more about the mono omission might be helpful. Or is anything “elliptic” broken? That seems like a major gap in the algorithms.

The SSH.NET folks know the area far better than we do. Would it be worth trying to work with them, even using the existing open unsolved mystery issue perhaps. Oh. I see we’ve already started on that path. :grinning:

Can’t connect (SCP, SSH) in Xamarin Android #807

EDIT:

Edwards-Curve Digital Signature Algorithm (EdDSA)
says ed25519 uses an Edwards curve, but that seems a variety of elliptic curve, so I’m looking for where
the gap in mono ends, so as to limit the amount of cutting (and probably security loss) that must be done.

1 Like

Here’s the candidate NotImplementedException, which looks specific to ecdsa:

EDIT: This might not be the exact line. See below for a possibly more accurate explanation.

Yep, this worked in my test.

I was able to reproduce the problem without Bitvise on Windows by simply reconfiguring the sshd service on my Mint machine to have RSA + ECDSA keys. Tested before your fix and had the ‘not implemented’ exception. After the fix, no exception and Duplicati showed me the RSA key fingerprint.

So yeah I think this is a good fix when Duplicati is running on mono.

1 Like

Thanks @drwtsn32 for testing. We should come up with something a little more robust in the actual code to defend against future changes to mono, but I think it would be pretty simple. I think in .NET 5, the responsibility is pushed to the operating system so future compatibility may be even more platform-dependent once we make that transition.

1 Like

Looking into this some more, I believe this might explain what we’ve discovered. This pull request added support for elliptic curve algorithms in SSH.NET. For ECDSA, it relies on the System.Security.Cryptography.ECDsaCng class

which is not implemented in Mono

For ED25519, SSH.NET provides its own implementation (from Choas.NaCl).

Here’s a draft of a potential fix. Testing is needed.

Nice, I’ll try to test it out today or tomorrow. Thanks!

Based on good earlier testing, I did some more research, and gave SSH.NET a theory of failure here, piggybacking on the existing GitHub issue. Theory still sounds good, but their confirm would be nice.

Can you test Control Panel → Server Management → Edit advanced settings → SSH algorithms → Signature, and see if unchecking all the ecdsa ones gets your Test connection and backup going?

image

@Rob_Canada can test similar if storage device is configurable. Some might need to know OpenSSH configuration, where I think @drwtsn32 knows more than I do (and doublecheck Bitvise above please).

Sorry for the delay in my response. I already implemented the workaround provided by @drwtsn32 earlier (removing the ECDSA host key on the Bitvise SSH Server), and I can confirm this works (now defaults to RSA host key).

Great work on tackling the root cause everyone. I assume the merge request will take some time to make it to the beta, but the workaround works fine, of course. Thanks again :slight_smile:

2 Likes

Release: 2.0.6.2 (experimental) 2021-05-29 is out with what is believed to be a workaround for the mono bug that broke SSH.NET that broke Duplicati. ECDSA host keys will not be used in mono until supported.

@Rob_Canada and @ghysler (and any others who saw this) are invited to remove workarounds from servers, and test it out. It should be safe to stay on, as it has only two changes from 2.0.6.1 Beta release, however you can set the Update channel back to Beta if you prefer to avoid future Experimental releases. Experimental is currently used as last step before Beta, so this code will probably be next Beta after test.

If you generally upgrade from Duplicati autoupgrader, you can go to Settings and change Update channel from Beta to Experimental, and it should offer this upgrade. If you prefer, installing manually will also work.

For best testing, please go to the Destination screen Advanced options, delete any ssh-fingerprint option, then use the Test connection button to accept a new one. Remember to go to final screen 5, to save it.

1 Like

I just updated to the 2.0.6.2 experimental version for the Synology, and it now works great!

Indeed, I again would like to thank everybody for such a great effort. I will stay on the Beta path but always look forward to the latest and greatest. On the rare occasion that something breaks, it’s fantastic to see such a vibrant community.

3 Likes