I run backups from various linux devices to a microserver on the LAN using sftp to a chroot jail on the server. It’s been working well for years.
The server and devices all run manjaro, yesterday an update to OpenSSH 8.8p1 seems to have triggered this error which prevents making backups.
My usual backup:
duplicacy backup -stats -threads 16 # which uses this: "storage": "sftp://email@example.com/repo"
Please describe what you expect to happen (but doesn’t):
Duplicacy runs a backup, progress is displayed in the terminal.
Please describe what actually happens (the wrong behaviour):
An error is thrown:
Storage set to sftp://firstname.lastname@example.org/repo Failed to load the SFTP storage at sftp://email@example.com/repo: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain
This is presumably happening because this version of OpenSSH deprecates SHA1 RSA keys: OpenSSH: Release Notes
And indeed sshd on the server side logs an error:
sshd: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] sshd: Connection closed by authenticating user duplicacy 192.168.0.8 port 44932 [preauth]
However I believe I’m using a 3000+ bit SHA256 key which should be valid:
ssh-keygen -l -f id_rsa # gives 3072 SHA256:[fingerprint-removed] root@computer (RSA)
And I’m able to access the repo when running sftp manually, including specifying the same key with -i:
sftp -i /root/.ssh/id_rsa firstname.lastname@example.org Connected to 192.168.0.10. sftp> ls -al drwxr-xr-x 3 root 968 3 Dec 19 2019 . drwxr-xr-x 3 root 968 3 Dec 19 2019 .. drwxr-xr-x 4 969 968 5 Dec 19 2019 repo sftp> exit
I’m able to make backups using the workaround of allowing ssh-rsa, by adding this to /etc/ssh/sshd_config and restarting the sshd service
On my LAN this is obviously not too much of a security worry. I’ll generate some new keys that don’t use RSA and then remove this.
But I’m posting this as a bug because I don’t see why manual sftp should work, but duplicacy running over sftp doesn’t.