Ssh: no common algorithm for key exchange

Support
#1

I’ve recently migrated laptop and updated Duplicacy to the web version all in one go. Previously, I backed up my Mac locally to an SFTP folder on my aged Buffalo Linkstation Duo NAS using the old Duplicacy client.

With my new Linux machine, I am using the web version of Duplicacy successfully to back up to remote B2 buckets. However, trying to add the same SFTP folder that previously worked gives the following error:

Failed to create the sftp client: ssh: handshake failed: ssh: no common algorithm for key exchange; client offered: [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1], server offered: [diffie-hellman-group-exchange-sha1 diffie-hellman-group1-sha1]

I doubt that my NAS will ever offer new key exchange algorithms - would it be possible to have Duplicacy support one of the key exchange methods that it offers?

Sftpc with duplicacy-web GUI
#2

diffie-hellman-group1-sha1 was specifically dropped from the default algorithms here: ssh: drop dh-group1-sha1 from default key exchanges · golang/crypto@094676d · GitHub

I’m not sure if it makes sense for Duplicacy to add it back. Maybe you can edit /etc/ssh/sshd_config on the NAS to add a supported algorithm like diffie-hellman-group14-sha1?

#3

Sadly the NAS is a closed box and I am unable to access the Linux system on it. I realise that supporting old algorithms isn’t necessarily sensible, but in this case, from an environmental standpoint it avoids me having to scrap an otherwise perfectly functional NAS that sits behind a firewall. I would really appreciate it if you could add diffie-hellman-group1-sha1 as an option, even if it has to be enabled by the end user with caveats around the risks.

#4

OK, slight update. It seems that I can enable SSH on the NAS (ironically, it is then hard to connect because of the whole key exchange malarkey).

Once in, I can see the following:

ssh -V gives OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.8ze 15 Jan 2015

adding the line

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 to /etc/sshd_config and restarting sshd with /etc/init.d/sshd.sh locks me out - future attempts to connect are refused.

Thankfully I can run remote commands without ssh enabled via ACP commander, so I could get myself back in with a little bit of sed surgery. I realise that I should probably be regenerating keys, but ssh-keygen -A returns

  -b bits     Number of bits in the key to create.
  -c          Change comment in private and public key files.
  -e          Convert OpenSSH to IETF SECSH key file.
  -f filename Filename of the key file.
  -g          Use generic DNS resource record format.
  -i          Convert IETF SECSH to OpenSSH key file.
  -l          Show fingerprint of key file.
  -p          Change passphrase of private key file.
  -q          Quiet.
  -y          Read private key file and print public key.
  -t type     Specify type of key to create.
  -B          Show bubblebabble digest of key file.
  -C comment  Provide new comment.
  -N phrase   Provide new passphrase.
  -P phrase   Provide old passphrase.
  -G file     Generate candidates for DH-GEX moduli
  -T file     Screen candidates for DH-GEX moduli

This feels like some sort of blend of archaeology and a tenacity test! Quite honestly I am not sure if this version of SSH supports newer key exchange versions - and although apt is installed, I can’t even run apt-get update successfully.

Not sure what to try next really - I can’t find anything sensible in /var/log/* and man is not even installed, so I can’t easily see whether OpenSSH 3.7 supports something sensible…

#5

You can debug sshd by running this command:

sudo /usr/sbin/sshd -ddd -p 222
#6

Results from that:

debug3: RNG is ready, skipping seeding
debug2: read_server_config: filename /etc/sshd_config
/etc/sshd_config: line 13: Bad configuration option: KexAlgorithms
/etc/sshd_config: terminating, 1 bad configuration options

So I guess I need to work out what that option should look like for OpenSSH 3.7…

#7

OK, having looked at the current ssh_config man page and the one for 3.7 it is clear that this option didn’t exist back then, perhaps because all key exchange formats were considered equally valid (and none considered weak). So that means I can’t do anything more to enable this.

Any chance of you enabling diffie-hellman-group-exchange-sha1 or diffie-hellman-group1-sha1? Or should I get shopping for a new NAS?

#8

This commit add a variation of the sftp backend sftpc:// that supports old key exchange algorithms. It will be included in the next release.

1 Like
SSH Handshake failed
#9

Thank you very much! I shall check this out :smiley: