Note that none of the offered HMAC algorithms are considered secure at this time and hence have been disabled by the security hardening on my server. Only encrypt-then-MAC algorithms are considered secure, of which none are supported by Duplicati. Please see this document for reference: Secure Secure Shell
I am currently using Duplicati version 2.0.3.11 Canary.
The SSH version on my server is as follows:
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017
despite its remarks favoring Encrypt-then-MAC. Don’t hmac-sha2-512 or hmac-sha2-256 fit your config? While I’m not a cryptographer, I see other sites (e.g. SSH.COM) putting these on their recommended list. Rapid, Secure Patching: Tools and Methods recommends them too, while retracting some earlier advice. Previously secure algorithms tend to fall over time, so it’s always wise to not be down to your last couple.
Support newer SSH Ciphers and MACs #53 looks like it would have to get some attention in the SSH.NET library before Duplicati can resolve this. Feel free to put in your support there for the requested change.
For Duplicati backups, its local encryption might also mitigate any vulnerabilities at SSH encryption level.
What about the security of the destination server where the backups are stored? There is far more to worry about than just the security of the off-site backup data. By adding those weaker algorithms I’d be compromising the security of the entire server, not just the backups. There is far more on the server than just the Duplicati backup data.
Then it sounds like the proper answer is to use a more up to date and in-development SSH library in Duplicati, no? SSH.NET doesn’t appear to have had any meaningful development in the past two years. It doesn’t even support modern algorithms such as EtM HMACs, Curve25519, and ChaCha20-Poly1305. I would argue it would be better to strip the feature entirely rather than continue to support obsolete and potentially insecure encryption. At the very least put a warning on it that it won’t work with a properly secured server.
In any event this is a show-stopper for my use of Duplicati. It’s a shame too because version 1 worked quite well using an FTPS target server (which is going away and not possible to set up on the new server).
SSH.NET is in development (last change Jul 30), but it’s not that active.
We’ve got an other difficulty with the library that it does not support the new OpenSSH format that ships by default in OpenSSH 7.8, at which point you have to go out of your way to generate keys on Linux that will work in Duplicati. Support new openssh format · Issue #465 · sshnet/SSH.NET · GitHub
I wonder if sticking strictly to encrypt-then-MAC knocks out almost all SSH implementations? OpenSSH seems to be taking the lead on this by using a non-standard binary packet protocol to avoid what Moxie Marlinspike calls The Cryptographic Doom Principle, which seems to be hardcoded into the standards that define SSH…
ssh(1)/sshd(8): Added support for encrypt-then-mac (EtM) MAC modes
for SSH protocol 2. These modes alter the packet format and compute
the MAC over the packet length and encrypted packet rather than over
the plaintext data. These modes are considered more secure and are
used by default when available.
OpenSSH Release Notes shows only one tweak to the etm modes, but I haven’t read any third-party analyses directly addressed at them. OpenSSH etm modes do seem to have been generally well-recommended though. Now if Duplicati could only find a way to get them portably. I wonder if interoperability was why hmac-sha2-512 and hmac-sha2-256 stays on the recommendations list from some of the experts or if there’s another reason?
If I were to do local backups (i.e. to an external disk) I’d just use the built-in Windows Image Backup which is superior to Duplicati for local Windows backups. (You can do both file-level restores and full-disk image restores with those.) The reason I was using Duplicati was to get off-site backups.
Rclone may work, I’ll have to look into it more, but in any event it’s a hack to work around an issue that should be addressed. If there was a 6-month roadmap that included a “this will most likely be fixed by then” I’d find it acceptable, but I don’t think it’s something I’d want to use long term. At best it’s one more point of failure in a system designed to be relied upon after failure.
The proper, and, from a security perspective, only, fix for this issue is to support modern encryption algorithms in the SSH library. I see two ways to go about doing that: fix the library, or replace the library. The Duplicati devs have the ability to do one of those, so the answer seems obvious.