I’m using a self-signed certificate and I’ve got an error with fingerprint verification. The message says “ssh-ed25519 256”, but the checksum appears to still be the same md5 16 bytes. It’s a good thing if the developers decided to upgrade the checksum verification to sha-256, since md5 is considered unsafe, but then the checksum should be different and 32 bytes in length.
The error message is related to the SSH library which was updated. IIRC, the default trusted algorithms are a bit stricter, which would explain the change in keys. I am not sure how the fingerprint is created, but the 16 bytes are returned from the SSH library (and server), and I think this is part of the key-file hash (including all lengths).
You can see the number after ssh-ed25519 is changed from 32 to 256, so what I understand from the error message is that you are seeing the same server key, but now using the 256 bit key instead of the previous 32 bit key.
I am not aware of any changes related to the temp folder.
I looked at the source and the intention of the --run-script-after option seems to be to delete the temp file immediately after the script exits.
I’m not hugely expert, but I notice that the ssh-ed25519 algorithm that’s named did not change.
This has multiple parts. After the algorithm comes a number, which it seems like library added.
2.0.7.100 Canary says ssh-ed25519 32 8F:2A:4E:F8:13:BC:79:B7:FA:44:DB:8B:A8:3F:18:FE
2.0.7.101 Canary says ssh-ed25519 256 8F:2A:4E:F8:13:BC:79:B7:FA:44:DB:8B:A8:3F:18:FE
2.0.7.101_canary_2024-03-08 release note show the library change, and no other suspects:
Updated SSH.Net, thanks @gpatel-fr
but from a Beta view, this is where it came out. Maybe Canary test didn’t recognize this issue.
I think the 16 bytes to the right of the mysterious changed number are MD5 of host public key.
$ cd /etc/ssh
$ ls *.pub
ssh_host_ecdsa_key.pub ssh_host_ed25519_key.pub ssh_host_rsa_key.pub
$ ssh-keygen -l -f ssh_host_ed25519_key.pub -E md5
256 MD5:8f:2a:4e:f8:13:bc:79:b7:fa:44:db:8b:a8:3f:18:fe root@LinuxMint21 (ED25519)
$
Ed25519: high-speed high-security signatures
Small keys. Public keys consume only 32 bytes.
Tested to another server (I have two varieties), fingerprint is stable:
2.0.7.100 Canary says ecdsa-sha2-nistp384 384 5C:69:6B:50:E0:E4:64:04:6A:4F:39:95:66:60:3A:5C
2.0.7.101 Canary says ecdsa-sha2-nistp384 384 5C:69:6B:50:E0:E4:64:04:6A:4F:39:95:66:60:3A:5C
I’m not sure what’s going on, but I’ll ask @hellcake if the server is some familiar type, e.g. OpenSSH?
Did the fingerprint work with 2.0.7.1 just before 2.0.8.1, and were there any ssh server changes done?
EDIT:
I think I found where the ed25519 key length gets converted from bytes to bits via a bug fix awhile back:
This probably explains one 32 becoming 256, but the change in the 16 byte MD5 still needs user’s info.
Fix ED25519Key KeyLength
The server is OpenSSH (preinstalled by a vds provider, but I’m certain nothing unusual about it). It was working before the update. No changes were made on the server side.
Looks like the case of 32 -256 change. It was the key length and before the update it was in bytes.
All Ed25519 are 256 bit. Likely 32 was the key length in bytes as @ts678 found out above
I don’t know why the fingerprint MD5 changed then. SSH fingerprint scheme is TOFU (trust on first use).
If you have access, you could SSH in to test what it thinks Duplicati should display for its MD5 fingerprint.
$ ssh-keygen -l -f ssh_host_ed25519_key.pub -E md5
256 MD5:8f:2a:4e:f8:13:bc:79:b7:fa:44:db:8b:a8:3f:18:fe root@LinuxMint21 (ED25519)
$ ssh-keygen -l -f ssh_host_rsa_key.pub -E md5
3072 MD5:54:40:5b:1f:39:ad:ff:6d:90:b4:16:bc:d0:5e:66:7c root@LinuxMint21 (RSA)
$ ssh-keygen -l -f ssh_host_ecdsa_key.pub -E md5
256 MD5:99:75:39:60:15:09:6e:14:c5:24:94:44:04:41:fe:dc root@LinuxMint21 (ECDSA)
$
continues on my testing above, and shows how fingerprint varies depending on the algorithm that’s used.
GitHub’s SSH key fingerprints covers a (likely) different scenario where all fingerprints are made identical.
You could ask your provider if they do that, but they might tell you to check for yourself, because they vary.
You could downgrade Duplicati to confirm you can flip the MD5 around. Maybe there’s another lib change.
I’d note that my test going to OpenSSH had no fingerprint change, only that fix to display the length in bits.
I didn’t say md5 was changed. In my first message, I initially thought the 256 part was related to the fingerprint. I thought it was changed because developers started to implement the sha-256 fingerprint.
Oh, my mistake then. Is there anything else to do here? If not, I might move this into its own topic because extended discussions on the release note will eventually make the release note very difficult to understand.
No, I will make a new topic on the fingerprint subject or just pull request if I have something to add. Thank you for your answer!
1 Like