I initially setup duplicati and got it running on one system with no problem. I did specify the ssh-keyfile under advanced options, but I did NOT specify the ssh-fingerprint (I didn’t even know about that). Yet, it worked. It seems to have grabbed the fingerprint on its own because now that option is there and filled out.
But I can’t for the life of me figure out where that fingerprint came from?!?! I’ve followed every guide I can regarding SSH fingerprint, MD5 fingerprints, server fingerprints, etc. I’ve found out how I can determine said fingerprints, but no matter what I do I can’t get the SAME fingerprint that duplicate auto-filled in! And the one I do get, doesn’t work.
I’m tearing my hair out here! What’s the secret sauce that I’m missing? Where did this fingerprint come from and how do I duplicate it if I lose it??
It’s from SSH server and it’s captured and remembered so that any attempt to put something else at the network address of the server will be noticed. Addresses by themselves are simple to change/intercept.
It’s as automatic as it was the first time, however I haven’t found any automatic ways, without admin help.
If you used the Test connection button on the Destination screen, you would get a blue popup that says
Trust host certificate?
No certificate was specified previously, please verify with the server administrator that the key is correct: ssh-rsa 3072 F3:B4:C6:F5:31:00:27:88:0B:89:73:31:9B:54:34:BA Do you want to approve the reported host key?
If you just went for a backup without testing, you get different more manual (not sure why) guidance saying
Error while running test_1
Please add --ssh-fingerprint=“ssh-rsa 3072 f3:b4:c6:f5:31:00:27:88:0b:89:73:31:9b:54:34:ba” to trust this host. Optionally you can use --ssh-accept-any-fingerprints (NOT SECURE) for testing!
Either way, the remembering of the server fingerprint for SFTP (SSH) is in the destination Advanced option
--ssh-fingerprint The server fingerprint used for validation of server identity. Format is eg. ssh-rsa 4096 11:22:33:44:55:66:77:88:99:00:11:22:33:44:55:66.
Where is the SSH Server Fingerprint generated/stored? says how Ubuntu makes and stores a fingerprint.
Note that this is for you to be able to know that you can still trust the server, not to get server to trust you…
I’m curious what system you’re using, because there’s no “blue popup” when I hit test connection?!? I get nothing warning about verification at all. And while this auto-magically got self-entered the first time, it has since refused to come back! Even with a fresh install, so I’m thoroughly confused. And the fingerprint it DOES accept (the one it self-determined) doesn’t appear to actually relate to anything! I’ve pulled md5 fingerprints from every ssh-related file on both the sending and receiving side, and NOTHING matches to the fingerprint it is using (and the only one it will accept). I can change the keys, and still it only accepts that first fingerprint.
That weirdness has me wondering if these aren’t the keys I think they are. Because I’m using Docker container, is it based on some internal-to-the-image id somehow?!?
I’m using a Windows system that does not already have SSH fingerprint. If you have that, try deleting it, however if you have none too, and it says nothing on Test connection or backup, that seems strange.
Have you looked in Destination screen Advanced options or Export As Command-line for fingerprint?
How does MD5 (obsolete and insecure) enter in, and what does “pulled” mean? This isn’t a file hash.
If you mean Duplicati Docker, which one (Duplicati or someone else’s). Or is sshd in a container?
Regardless, I don’t use Docker, so I can’t get into details, but don’t keep data in the container itself.
EDIT:
In addition to (and in basic agreement with) the earlier link I posted, here’s a recipe for getting fingerprints:
Although I doubt it’s the case, if Duplicati Docker comes with a preinstalled ssh-fingeprint, that’d be a bug. Docker for the sshd side seems potentially likely to use the same /etc/ssh files, so may be prone to this…
THANK YOU! I installed the Windows version and then I see the blue window you’re referencing. I copied and pasted that fingerprint into my docker install and it works. That window DOES NOT COME UP on the docker install.
Which brings me to:
Someone else’s… currently. I’ve gone back and forth. I’m using linuxserver/duplicati because I was having trouble with duplicati/duplicati and reverse proxy, which turned out to be unrelated. So yes, I suppose the “bug” could be related to the distro.
It isn’t? Ok, then color me confused. From my reading of various ssh fingerprint guides, the gist I got was that it was a hash of the id_rsa (or whatever) file. Certainly the format looks like MD5 and I agree it is is obsolete so I wondered why it was being used. The format doesn’t look anything like what a modern install of ssh outputs. Anyway, I don’t need to fill up my brain with the how’s and why’s of those details… I just wanted it to work and you’ve gotten me there.
It won’t take long, so I’ll fire up a duplicati/duplicati install and see if I get the same behavior.
Installed a fresh copy of duplicati/duplicati and I did see the blue window that was previously missing.
So either my config was somehow buggered, or something’s wrong with linuxserver/duplicati I guess? I’m not investigating further, but this can be considered a “move along, nothing to see here folks”.