Unable to connect to rsync.net ssh: handshake failed: ssh: unsupported DSA key size 2048

I ran unset SSH_AUTH_SOCK and then ran rclone --sftp-ask-password lsd rsyncnet: again and still receive same error

I have an `rsync.net account with config like this

[rsyncnet]
type = sftp
host = usw-sXXX.rsync.net
user = 5XXXX
pass = *** ENCRYPTED ***
md5sum_command = md5 -r
sha1sum_command = sha1 -r

And it works just fine.

I found a relevant issue

Which seems to suggest it is something to do with out of range DSA keys. I'm not sure where that key is though. Is it in your .authorized_keys on your rsync net server? Or maybe there is an .ssh/id_dsa file?

Thanks for your help on this. I tried it just now using your config, and it still throws the error. I don't have an .authorized_keys file on my rsync net server. I don't even have an .ssh directory

I can ssh just fine into my server: ssh user@subdomain.rsync.net ls works great

I am having this same issue with a fresh install of rclone on both my linux VM inside chromeOS, and also a fresh Vultr vps running Debian 10.

Here's my exact steps:

  1. spin up vultr vps and ssh into it
  2. ssh into my rsync.net account from the vps to test the connection
  3. install rclone using the one-liner from rclone.org
  4. configure rclone, exactly as you described in the post above
  5. run rclone lsd rsyncnet:
  6. get error: 2020/05/13 21:38:09 Failed to create file system for "rsyncnet:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unsupported DSA key size 2048

Is DSA being used somewhere in the SSH handshake?

I've emailed rsync.net support and they asked if there's a way to choose a cipher other than DSA?

Is there an 'ssh options' option where you can specify ssh command line
switches and, with those, you could choose a cipher other than DSA ?

Update: just tried with ask_password in the config instead of pass and I'm getting the exact same problem. Very confusing.

I am facing the same problem.

I can add from my side, that the same error is thrown on my fresh Fedora 32 server as well as my Windows Server 2019. Both are running rclone 1.51.0, installed through package managers (dnf on Fedora, chocolatey on Windows).

Since at least the Windows system never has seen a ssh key, I suspected that mysterious DSA key to be on rsync net's side, but ssh-keyscan shows no DSA key fingerprint:

❯ ssh-keyscan ch-s010.rsync.net
# ch-s010.rsync.net:22 SSH-2.0-OpenSSH_7.5-hpn14v5 FreeBSD-openssh-portable-7.5.p1_1,1
# ch-s010.rsync.net:22 SSH-2.0-OpenSSH_7.5-hpn14v5 FreeBSD-openssh-portable-7.5.p1_1,1
# ch-s010.rsync.net:22 SSH-2.0-OpenSSH_7.5-hpn14v5 FreeBSD-openssh-portable-7.5.p1_1,1
ch-s010.rsync.net ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKBxDZv64oRMzRkywjmRRrml2pr0XFSZhlL46nUSmM60
# ch-s010.rsync.net:22 SSH-2.0-OpenSSH_7.5-hpn14v5 FreeBSD-openssh-portable-7.5.p1_1,1
# ch-s010.rsync.net:22 SSH-2.0-OpenSSH_7.5-hpn14v5 FreeBSD-openssh-portable-7.5.p1_1,1

my authorized_keys file is also empty on both sides.

So from my understanding of SSH there seems to be no DSA key involved at allon any side.
I'd be quite interested in the answer from rsync net (could contact them myself, but documenting the problem and steps to solve it is a better way, I think).

1 Like

I'm grateful this thread exists, because I couldn't find anyone else reporting this problem. I'd encourage you to open an email with rsync.net so that they have more information to work with if the problem is on their end. Perhaps they can identify a commonality with our accounts that is causing the issue. It's odd that @ncw's account is working fine, perhaps you and I have an account on a different server, or service level?

It's actually worked for me a couple of times over the last 1.5 weeks, but it would be very random and I'd have trouble duplicating the connection. Over time it connected less and less often, no matter how often I'd try, and just a few days ago it quit connecting entirely.

you are correct and I just sent a mail to them with some more details from my side and linking to this thread in case they want to take a look.

rsync net also publishes the fingerprints of their servers, which lists a DSA fingerprint. But a fingerprint isn't a key and to my knowledge shouldn't trigger the function described in the linked Github issue with the same error message.

But I also don't know Golang very good or the internals of how the ssh command initializes the connection. I was of the impression that fingerprinting comes after aquiring a key to fingerprint against.

I can easily fall back to rsync or scp, but I'd rather use rclone for my specific use case.

This is definitely something to do with the rsync.net host

Here is me attempting to login with user test and random password which will fail, but checks the auth.

Here is @saschatrebbin 's host which shows the error

$ rclone lsd --sftp-host ch-s010.rsync.net --sftp-user test --sftp-ask-password :sftp:
Enter SFTP password: 
2020/05/14 11:42:48 Failed to create file system for ":sftp:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unsupported DSA key size 2048

And here is mine which doesn't

$ rclone lsd --sftp-host usw-s009.rsync.net --sftp-user test --sftp-ask-password :sftp:
Enter SFTP password: 
2020/05/14 11:43:51 Failed to create file system for ":sftp:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain

And here is my host also showing the error

rclone lsd --sftp-host usw-s001.rsync.net --sftp-user test --sftp-ask-password :sftp:
Enter SFTP password:
2020/05/14 17:55:49 Failed to create file system for ":sftp:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unsupported DSA key size 2048

@ncw is correct, this is on rsync.nets side. This is the the answer I got from rsync net:

Hi,

While rclone figures out how to get around this, we would like to solve this for you by moving your account to a server that offers a DSA key with a length of 1024.

You can test this by connecting to this TEST account:
account: <TEST_LOGIN_NAME>@ch-s011.rsync.net
pass: <TEST_PASSWORD>

This would require a hostname and login ID change and we can move your existing data over. May we do this now?

I'd rather not post the full login here, even if it is a test account. But using that login info with rclone 1.51.0 on Windows worked. I'll let them move my account to another server, then this is solved for me. @jjaarrvviiss I expect a similar answer to your mail to their support.

this is enough to test the behavior:

λ  rclone lsd --sftp-host ch-s011.rsync.net --sftp-user test --sftp-ask-password :sftp:
Enter SFTP password:
2020/05/15 07:07:19 Failed to create file system for ":sftp:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain

I received a similar email albeit with less details and also a request to move my account. I agreed to the move and am waiting to hear back. Glad to hear things are working for you!

I tried patching the ssh library to allow 2048 bit DSA keys

Can you give this a go please?

https://beta.rclone.org/branch/v1.51.0-325-gc4700f4b-fix-ssh-dsa-length-beta/ (uploaded in 15-30 mins)

I've no idea whether it will actually work though!

Damn, my account was just migrated.

But the basic test you provided above now works with my old host:

C:\Users\saschatrebbin\Downloads\rclone-v1.51.0-325-gc4700f4b-fix-ssh-dsa-length-beta-windows-amd64\rclone-v1.51.0-325-gc4700f4b-fix-ssh-dsa-length-beta-windows-amd64
λ  .\rclone lsd --sftp-host ch-s011.rsync.net --sftp-user test --sftp-ask-password :sftp:
Enter SFTP password:
2020/05/15 11:46:46 Failed to create file system for ":sftp:": NewFs: couldn't connect SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain

So I guess that patch works and allows these non standard DSA keys.
Since seemingly both affected users are migrated to new hosts that do not need this patched behavior, do you feel the need to go forward with that patch, @ncw?

For me the migration to another server was painless, so I'd view your patch as an unnecessary burden on the rclone project. But my case might not be representative.

I don't know whether that is enough of a test to see it works - I'd like to see a successful login!

If it works I was going to submit it to the upstream ssh library that rclone uses. It is a very simple patch...

My account hasn't been moved yet, so it's still on the old server. testing this patched version of rclone works well for me! rclone ls and rclone sync work fine both ways!

They migrated my account now too, so I am able to use version 1.51.0 with their existing servers. Until they migrated I was able to use version 1.51.0-325-gc4700f4b-fix-ssh-dsa-length-beta just fine, your patch works great.

Great! I'll send the little patch I made upstream which will make its way back into rclone eventually.

1 Like

Thanks so much for your help @ncw and @saschatrebbin

Thanks again for patching to support 2048 length DSA keys.

Just a followup to document another solution:

Support at rsync.net suggested forcing the use of ssh-ed25519 by using the HostKeyAlgorithms option.

You can add the following line to your ssh config (~/.ssh/config):

HostKeyAlgorithms ssh-ed25519

You can add the following line to your rclone config (~/.config/rclone/rclone.conf)

path_override = ssh -oHostKeyAlgorithms=ssh-ed25519

Or you can pass an option via the command line using --sftp-path-override

--sftp-path-override "ssh -oHostKeyAlgorithms=ssh-ed25519"

That won't work with rclone as it doesn't use the system ssh alas

This is what the path_override config var is for... It won't let you use the system ssh (though that isn't a bad idea for a different flag).

--sftp-path-override

Override path used by SSH connection.

This allows checksum calculation when SFTP and SSH paths are
different. This issue affects among others Synology NAS boxes.

Shared folders can be found in directories representing volumes

rclone sync /home/local/directory remote:/directory --ssh-path-override /volume2/directory

Home directory can be found in a shared folder called "home"

rclone sync /home/local/directory remote:/home/directory --ssh-path-override /volume1/homes/USER/directory
  • Config: path_override
  • Env Var: RCLONE_SFTP_PATH_OVERRIDE
  • Type: string
  • Default: ""
1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.