The preferences don't seem to be using the ssh key file

Support
#1

Hey I have a working repo that uses the key file from .duplicacy/preferences (keys:ssh_key_file) via the x86 command line interface (2.7.2 (175ADB)). But, I can’t get this to work with my other repo on a remote machine. To be clear, I have ssh keys setup and working and I’ve pointed to said keys, but for some reason it always asks for the ssh password on the remote repo. I also created a second repo just for testing. With the exception of my default storage, it always asks for an SSH password.

[
    {
        "name": "default",
        "id": "mydata",
        "repository": "",
        "storage": "sftp://username@local_ip//backups/duplicacy",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "nobackup_file": "",
        "keys": {
            "ssh_key_file": "/.duplicacy/ssh/id_rsa"
        },
        "filters": "",
        "exclude_by_attribute": false
    },
    {
        "name": "remote",
        "id": "mydata",
        "repository": "",
        "storage": "sftp://username@remote_ip//backups/duplicacy",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "nobackup_file": "",
        "keys": {
            "ssh_key_file": "/.duplicacy/ssh/id_rsa"
        },
        "filters": "",
        "exclude_by_attribute": false
    }
]
#2

If the key file is encrypted by a passphrase, you’ll need to set ssh_passphrase in the preferences.

Running duplicacy -d list -storage remote may explain why it was asking for the ssh password.

#3

I got it to work by adding this to my sshd config.

PubkeyAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

Is this a duplicacy specific issue? I’m able to use the same set of keys to connect via ssh and sftp without the above addition.

#4

If your server only supports outdated ciphers (can’t see the long line in your message on the phone to confirm if this is the case) you can use sftpc duplicacy backend instead of sftp to enable outdated ciphers.

#5

It’s a brand new installation of ubuntu server 22.04. Additionally, the keys work when I use ssh/sftp, so I’m not sure what duplicacy is doing differently.

#6

After upgrading a laptop to Ubuntu 22.04 LTS I had trouble logging onto servers running old versions of RHEL/CentOS. With OpenSSH in verbose mode (“ssh -v”), I could see that the key exchange was failing. Then it was the opposite problem when trying to use Duplicacy 2.7.2 to connect to an Ubuntu 22.04 LTS server.

The SSH/SCP/SFTP connection handshake involves negotiating shared algorithms for keys, signatures, ciphers, etc. Any algorithms that are supported by the client but not the server – and vice versa – are excluded. If neither side can agree on a set of common algorithms, the connection fails.

Ubuntu 21.10 was bundled with OpenSSL 1.1.1l while Ubuntu 22.04 shipped with OpenSSL 3.0.2u (DistroWatch.com: Ubuntu). Older RSA variants, hash algorithms, ciphers, etc. have either been disabled by default or dropped due to security issues.

My guess is that the version of the ssh package (https://golang.org/x/crypto/ssh) compiled into Duplicacy 2.7.2 still uses the older RSA variants.

Instead of overriding the default list of key types in sshd_config, it’s possible to add only the older ones that are needed. For your RSA key…

PubkeyAcceptedKeyTypes +ssh-rsa

(The ‘+’ modifier at the start of the list specifies append mode.)

However, a better option would be to replace the RSA key with an Ed25519 key (supported by Duplicacy) so that there’s no need to enable less secure key types.