0

I am trying to setup a backup server using duply and a secure connection.

I have created the ~/.ssh/config file with the following content:

Host backup
  IdentityFile ~/.ssh/id_ed25519_backup
  Hostname <server_ip>
  Port 22
  User <user_on_host>

Furthermore, I have also defined the known_hosts file, by copy-pasting in it the server public key (found in /etc/ssh/ssh_host_ed25519_key.pub)

All seems to work properly when using the ssh -v backup command:

Authenticated to <server_ip> ([<server_ip>]:22)

However, when launching duply backup routine, I see that the server is not recognized:

The authenticity of host '[<server_ip>]:22' can't be established.
SSH-ED25519 key fingerprint is c3:06:95:f8:5f:d3:76:7f:c6:9d:19:ef:e5:23:9a:14.
Are you sure you want to continue connecting (yes/no)?

Why is this happening?

Update

It seems that duply is computing the MD5 hash of the public key, while ssh the SHA256 one: in fact, as mentioned here, ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ed25519_key.pub returns the same hexadecimal stated above. Since they are two different hash of the same key, why a connection confirmation is still asked? Is it possible to oblige SSH to use only a single hash algorithm?

Further update:

ssh -o FingerprintHash=md5 -v backup does not require confirmation, so I suppose that the issue is limited to duply. Maybe, does it not refer to the user known_hosts file?

rudicangiotti
  • 123
  • 3
  • 10
  • 1
    My guess is that the line in `known_hosts` is for a server named `backup`. If so, try adding a line with the same public hostkey for ``. – berndbausch Feb 21 '21 at 01:56
  • @berndbausch, in `known_hosts` I have the server IP hashed, key type and value. I have added all the public keys of the server (ssh-dss, ecdsa-sha2-nistp256, ssh-ed25519 and ssh-rsa) but it is still stated as unknown. – rudicangiotti Feb 21 '21 at 02:08
  • Then I would double-check the fingerprint of the key that you entered in `known_hosts`. The command is `ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub`. Also, more verbosity (`ssh -vvv`) should show you how the SSH client cycles through the content of `known_hosts`; perhaps that reveals something. – berndbausch Feb 21 '21 at 02:15
  • @berndbausch, using the command you suggested, I probably found the source of the issue and so I updated the question. – rudicangiotti Feb 21 '21 at 14:50
  • 1
    I am not familiar with `duply`, but having a quick look at the source, it seems to come with its own profiles, so potentially it doesn't even look at the `~/.ssh/config` you created. So I guess you'll need to have a closer look at `duply` configuration. – dirkt Feb 21 '21 at 16:28

1 Answers1

0

duply is built upon the Paramiko python module and checking more in depth its implementation, it seems that Paramiko is not able to manage hashed known hosts. I have then modified the SSH configuration file /etc/ssh/ssh_config by setting HashKnownHosts no, and rewritten the content of ~/.ssh/known_hosts by inserting in clear target IPs and/or domains.

rudicangiotti
  • 123
  • 3
  • 10