I exported a configuration then imported it to set up a duplicate backup to a different machine. The config included a url to the sever with the server fingerprint in it. I changed the server after import in the configuration menus via the GUI and tested the connection (no error reported); the ssh connection worked fine from the console. Yet the backup up failed because of the server fingerprint. The user interface doesn’t seem to give any access to the server fingerprint. It was necessary to edit it out manually in the config file before (re)importing it.
This could be improved in one several ways:
remove the fingerprint if the server is changed
make sure the test connection also checks the fingerprint
Destination screen Advanced options has it. Click its x to delete, then Test connection to accept new one.
I kind of wonder if the Test connection behavior for a wrong fingerprint is a bug. Mine just sits there awhile.
Most controversial from a security point of view is to delete current fingerprint when the server is changed.
If such a change was an attack, this would seem to make it too easy for a non-expert to accept the attack.
Thanks and sorry - I didn’t realise it was in the Advanced settings. I don’t have a strong opinion about the correct “solution”, I just wanted to record a point of some confusion that I encountered.
That said, I think the connection test should report an error if launched and the connection fails, in general, and ideally point to the advanced settings in this particular case?
Does it ever make security sense to retain a fingerprint for a new server?
We seem to be in agreement. If you saw no report too, can you file an Issue? Forum doesn’t track.
I think you typically want them to be different and unique. Sometimes cloned VMs may mess that up.
If you’re arguing for your option 1, the challenge may be in adding historical awareness of the server.
Somebody might also ID the same server by a different DNS name. That shouldn’t kill the fingerprint.