Server HMAC algorithm not found

1

Hi!

until June my backups with sftp works, but after then i only got “Server HMAC algorithm not found”. I am using ssh/sftp with ppk file (which i converted with puuygen). All that went well for years until a few months ago.

I have testes the connection also with syncovery, it seems to be okay.

ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
…

I updated ro 1.9.0 already.
Any ideas?
Thanks,
Tom

2

Welcome to the forum @DarthWeber

Updated what thing? Who controls the server? Did anything change that might have caused this?

Duplicati has little to do with ssh client, but a lot to do with your server which is why I ask about it.

https://github.com/sshnet/SSH.NET/tree/2023.0.1 describes what crypto your Duplicati may have. Some might be limited by things like mono encryption. What Duplicati on what OS is this running?

3

I updated Duplicati to 2.0.8.1 - and tested on windows as well as ubuntu. The server is commercial, i got the info i need to use one of

hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh (dot) com
umac-128@openssh (dot) com
hmac-sha1-etm@openssh (dot) com
hmac-sha1-96-etm@openssh (dot) com
hmac-sha2-256-etm@openssh (dot) com
hmac-sha2-512-etm@openssh (dot) com
hmac-md5-etm@openssh (dot) com
hmac-md5-96-etm@openssh (dot) com
umac-64-etm@openssh (dot) com
umac-128-etm@openssh (dot) com

4

I suppose the easiest next thing is to test them on that using -m mac option, for example:

$ ssh -m hmac-md5 <host>

The SSH server I tested doesn’t accept that one, and the OpenSSH client tells me so with:

Unable to negotiate with REDACTED port 22: no matching MAC found. Their offer: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

If you drop the -m mac and add -vvv to the command, I think you can study the negotiation.

At least the first six items they claim to support match what SSH.NET also claims to support.

5

ssh -m hmac-md5 xxxxxx seems to work:

ssh -m hmac-md5 xxxxx
Password:

Thanks,
Tom

6

You can add -vvv to the command to start a more complete study of the negotiation.

Usually what happens is a server starts denying the older crypto, so I tested an md5.

Since they accept that, then I don’t know why they dislike all the ones Duplicati does.

The next step might be to do a packet level study, unless someone has a better idea.

How are Ciphers, MACs and Key exchange algorithms negotiated by OpenSSH?
summarizes the answer, and points to the RFC that gives a more official explanation.

Using Wireshark or tshark, I think you look at Client and Server key exchange init for:

ssh.mac_algorithms_client_to_server
ssh.mac_algorithms_server_to_client

and you can try the -vvv option in ssh as a warm-up to see what server is permitting.

Is this commercial server on the Internet, with documented host name you can post?

7

If you want to look at the protocol traffic yourself, read “Algorithm Negotiation” below.

Understand Secure Shell Packet Exchange

If your Duplicati config is using SSH Advanced options, does simpler get any further?
Algorithms are negotiated very early, so you don’t need to actually proceed to a login.

8

Looking for an SSH expert because seemingly my above is not the complete negotiation story.

Currently I can see OpenSSH saying it does only hmac-md5, server not having it – yet success.

As a side note, server kexinit claims to do only a few etm algorithms. 2024’s SSH.NET has them.
Duplicati hasn’t picked that one up yet.

9

Using the -vvv supports a theory on how the -m hmac-md5 managed to get by. If I also add

-c aes128-ctr

the ssh ends at

Unable to negotiate with <server> port 22: no matching MAC found. Their offer: umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

The clue from verbose output was

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

and wondering what an <implicit> MAC was. Some Google searching led me to this post on it:

SSH MAC Algorithm

and I think it’s saying that the MAC choice was implicit in the cipher choice (which both ends do).

ChaCha20-Poly1305 (Wikipedia) says ChaCha20 is its stream cipher part and Poly1305 is MAC.

Unable to connect chacha20-poly1305@openssh.com or GCM #1374

got closed, but actually only on the GCM side for current reasons explained in the pull request at

Add support for AEAD AES 128/256 GCM Ciphers (.NET 6.0 onward only) #1369

Presumably the server side introduced this very limited support then, although they claim more. Duplicati might update to the 2024 library later, but it may have to be a Canary test release first.

This list seems to be wrong based on what’s actually coming from server. Can they loosen any?

1 Like
10

For completeness, I’ll note that -c aes128-ctr by itself without MAC limit can connect in ssh.

Ideally their server will change its config to allow a MAC that is supported (see previous link).

If that’s impossible, you can see if rclone SFTP can access. If so, Duplicati can use it instead:

Rclone (rclone):
 This backend can read and write data to Rclone.
 Supported options:
  --rclone-local-repository (String): Local repository
    Local repository for Rclone. Make sure it is configured as a local drive,
    as it needs access to the files generated by Duplicati.
    * default value: local
  --rclone-remote-repository (String): Remote repository
    Remote repository for Rclone. This can be any of the backends provided by
    Rclone. More info available on https://rclone.org/.
    * default value: remote
  --rclone-remote-path (String): Remote path
    Path on the Remote repository.
    * default value: backup
  --rclone-option (String): Rclone options.
    Options will be transferred to rclone.
  --rclone-executable (String): Rclone executable
    Full path to the rclone executable. Only needed if it's not in your path.
    * default value: rclone
11

Hi,

rclone is not allowed by the company. The also informed me that md5 is outstanded and a security problem, so they disabled it.

Is one of those MAC possible?

umac-128-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com

12

I agree, and had no intention of suggesting they turn it on. As noted:

and yet they gave it to you on their big list? Or maybe a different source gave list here?

As noted:

so not possible now, and developer would have to speak about future. There’s a new ask for it:

Server HMAC algorithm not found #4674

We see the same issue with Duplicati SFTP after our latest round of SSH/SFTP server hardening, which removed the hmac-sha2-512 and hmac-sha2-256 MACs flagged as weak by ssh-audit due to their encrypt-and-MAC method.
So +1 from here to the suggestion about upgrading the dependency to SSH.NET 2024.x, which added support for a number of modern MACs.

13

Thanks for the link. I have made a PR for upgrading SSH.NET.

It will be in the next canary build, due today or tomorrow.

1 Like
14

Possible now with the new build, thanks a lot.

Only issue: The fingerprint match doesn’t seem to work right. I get success on testing the connection, but during the backup it claims that the fingerprint is wrong. With “accept any fingerprint” it is no problem.

I double checked the fingerprints and see no difference.

15

Can you share the error message and the fingerprints that are reported?

16

If you did that while trying to solve this problem, it’s possible that you ran into this change:

2.0.8.1 update may request SSH/SFTP ssh-ed25519 host key reverification

Did you look at the whole thing including the length value?