In a way, I installed it immediately - unfortunately. Since then, the backup via SSH no longer works. I saw in the release notes that it can happen that the backups fails as the host key is reported as “changed”.
I have changed the SSH key in the configuration. Unfortunately, the backup does not work, as every time it complains that the key is not correct.
The message is:
"May 4, 2021 2:20 PM: The operation Backup has failed with error: Validation of server fingerprint failed. Server returned fingerprint "ssh-ed25519 32 20:21:c1:b7:e4:e6:1f:e0:f6:03:aa:bb:cc:dd:ee:ff". Cause of this message is either not correct configuration or Man-in-the-middle attack!"
The SSH backend has been updated
This update increases the security by prefering stronger encryption algorithms.
However, this can cause failing backups as the host key is reported as “changed”.
If this happens, edit the backup and update the host key.
You can find this option on Destination screen 2. Click x to delete previous value.
Next SFTP (SSH) access will ask you to accept the new value that it provides you.
Basically, this is like original setup that you would have done for your old fingerprint.
Thank you very much for the advice. I have just found the error. I had deleted the SSH key and pressed the “Test Connection” button. Duplicati then asks if you want to trust the key. After I did this, the backup worked again.
The difference now were the quotes.
Wrong (like suggested by the help message (if i remember right)):
This seems unlikely to work at a Windows Command Prompt, as it needs quotes to keep going across the spaces, otherwise it assumes the space ends that value. It seems unlikely to work in the GUI because GUI doesn’t use the CLI option double-dash convention. The unquoted values go directly into the GUI input area.
Possibly the message had CLI in mind, intended to solve the CLI broken-by-spaces.
Where does fingerprint come from with SFTP (SSH)? has sample messages from so meprevious testing.
Looking at that suggests that your method is probably the easiest way to get a fingerprint back after delete:
and that probably didn’t get into any difficulty about GUI-versus-CLI-quotes, option-dashes-versus-not, etc.
Well, I’m stuck. All I get since this update is an immediate “failed to connect” and never any “do you want to add this fingerprint”, etc. That’s when using docker/linux. I installed it on Windows and I do get that message. It id the identical fingerprint as was already in there though. Still, with that in place it fails to connect.
No other changes than installing this update. I don’t know what to do.
2 hours, and the only “solution” I’ve come up with is to enable the Allow All Fingerprints option, which is an obvious security flaw. I know I ran into this issue before that once a fingerprint was accepted the system NEVER asks again, whether or not I delete the one that’s there. The “solution” before was to do a fresh install, which stinks.
I tried deleting the config directory and letting docker rebuild it. That didn’t help. I tried deleting the known_hosts file. That didn’t help. I’ve confirmed that my systems have no problem at all ssh’ing to each other. The only feedback I get from duplicati is “failed to connect”.
Did you try the release note method given earlier that worked OK here?
In Advanced options, delete fingerprint
Press Test connection and accept?
Which config directory? Docker won’t rebuild ~/.config/duplicati. Settings are in Duplicati-server.sqlite.
Duplicati doesn’t use OpenSSH, which is non-portable native code. It uses SSH.NET. I found one issue with fingerprints reported there, 10 months into Beta, so it seems more likely that your issue is Duplicati.
If the two-step fix doesn’t work, then you could Export As Command-line and see if you see a fingerprint after you deleted the most obvious one. It might be possible that your old fingerprint is stored elsewhere.
Yes, I tried deleting the fingerprint and using Test… as I said, it just immediately says Failed to Connect. It never shows me any option for using a new fingerprint (but it did the very first time I ran duplicati).
The “config directory” I mean is the persistent host folder defined as a volume when running this app as a container. So in my case -v /opt/duplicati:/data.
In any case, I did figure out a solution finally. I created a new temporary/dummy entry into my docker-compose.yml file to make a second instance of duplicati (called it duplicati2) with a different /data location (eg /opt/duplicati2) running on a different port and then started to make a test backup. Since this was the “first” time it was run, it did indeed offer me the are-you-ok-with-this-fingerprint thing, and I copied that and pasted in the previous instance’s backup config settings and all is ok in the world.
why in the world it refuses to show me that message, I do not know. It is frustrating but hopefully the next time it happens I’ll find this thread and see what to do to resolve it.
Nb: one issue may be that I originally didn’t know there was a duplicati/duplicati docker and I was using linuxserver/duplicati. I can’t for the life of me figure out why that would matter, but on a 2nd system I have that has only ever had duplicati/duplicati running… I do not have this same issue.
Side note: what’s really weird is that I installed a copy on my windows machine and tried connecting to the server and the fingerprint it gave was identical to the one I already had?!? Why would that be? I mean, that’s a fresh install connecting to the server for the first time and it saw the server as using the older style fingerprint.
By “older style”, I mean my old one was ssh-rsa 3072 D5:A5:FE:B0:02:XX:XX:XX:EE:E8:F7:FA:10:15:7D:BD
Do you recall what you saw in there? I don’t use Docker, but I’d expect a Duplicati-server.sqlite and some random-letters.sqlite files which are per-backup. If you delete all, you should have no jobs and no backup databases, although if you can recreate the jobs, e.g. from prior Exports, you can Repair to rebuild those.
