No secure HMAC algorithms offered for SSH/SFTP

When attempting to use SSH/SFTP with a security-hardened SSH service I receive the following error:

“Failed to connect: Server HMAC algorithm not found”

On the server, I have this line in my logs:

Oct 2 17:43:04 [redacted] sshd[4293]: Unable to negotiate with [redacted] port 59368: no matching MAC found. Their offer: hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com [preauth]

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

The referenced article says:

Recommended /etc/ssh/sshd_config snippet:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

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.

See here for a more in-depth discussion of why Encrypt-Then-MAC is required and everything else is unacceptable: encryption - Should we MAC-then-encrypt or encrypt-then-MAC? - Cryptography Stack Exchange

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

Would mounting the destination locally and using that as local destination solve your issue? Or use the rclone backend?

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…

Changes since OpenSSH 6.1

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

SSH implementation comparison – Message authentication codes (MACs) shows few offerings of -etm modes, however one interesting one present is PuTTY even though they seemed uninterested to that request at first.

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?

P.S.

The idea from @Wim_Jansen is interesting. I’m not sure what rclone has under it to do sftp (then ssh below), but "hmac-sha2-256-etm@openssh.com" appears in https://github.com/golang/crypto/blob/master/ssh/mac.go and there’s some discussion (not even sure if it’s that code) at x/crypto/ssh: support additional MACs #17676. Easier than sorting through all the code might be to see if Rclone destination does any better on algorithms…

Mounting it in is totally valid, but it’s kind of a work-around. Performance should be fine, tho.

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.