Plain old ssh and sftp don't encounter the error, and I also tested SFTP on Windows Filezilla with no problems (which all required me to verify the host's key).
Run the command 'rclone version' and share the full output of the command.
rclone v1.57.0
- os/version: Microsoft Windows 10 Enterprise 2009 (64 bit)
- os/kernel: 10.0.19043.1526 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.17.2
- go/linking: dynamic
- go/tags: cmount
Which cloud storage system are you using? (eg Google Drive)
The command you were trying to run (eg rclone copy /tmp remote:tmp)
This sample command uses a dummy user ID, which works to replicate the error because it happens even before rclone can prompt for a password. I've tested it with my actual user ID and with --sftp-key-file instead, and both encounter the same error.
I also tested the same command on an Alpine Linux VM and can get the same signature error.
FWIW, I just did a "ssh rsync.net" and accepted the key it supplied.
Oh, tried it out and I see a discrepancy on my end.
When I ssh rsync.net, my ssh picks up the ssh-ed25519 key, while yours is getting the ecdsa-sha2-nistp256 key. An ssh-keyscan rsync.net shows that it has 3 keys:
Rclone's ssh implementation is either trying to use a key that's not in known_hosts; it's trying to use the ecdsa-sha2-nistp256 when it's only ssh-ed25519 that's available in the known_hosts file.
Rclone's ssh implementation can't do the ssh-ed25519 handshake, but can do the ecdsa-sha2-nistp256 handshake.
I'll try checking their other servers to see if there's one that doesn't use ssh-ed25519 . Maybe rclone can complete handshakes with those.
My recommendation: list all of them in the known_hosts file. If the Go SSH library is half-way sane it'll try all of them (that's what OpenSSH does, but I have a vague memory that the Go library isn't quite so smart). If it fails then just try them one at a time.
The key that's used will depend on the cipher suite negotiated.
correct about the base64 but your text did not work, known_hosts:1: ssh: short read
i went to https://www.base64encode.org jJCISHUXooV9/rh7kSeqiSuPvOVWBFCOe2CNkwTO46o
becomes akpDSVNIVVhvb1Y5L3JoN2tTZXFpU3VQdk9WV0JGQ09lMkNOa3dUTzQ2bw==
and that works but get same error as OP.
so you solved my issue.
My recommendation: list all of them in the known_hosts file.
The problem is that for the server I was assigned (and for most of them in their fingerprint registry), there seems to be exactly just one key, according to ssh-keyscan.
Luckily, in the fingerprint registry I found another SFTP server with triple keys (sd1.rsync.net) and tried connecting to it. It turns out I get the same error only when the ecdsa-sha2-nistp256 is absent from the known_hosts file. So it does look like, at least in the multi-key case, Rclone is stuck using the ecdsa-sha2-nistp256.
I have no theory though on what happens when there's one and only one key. Maybe rclone is seeing more keys than ssh is? Can you check ssh hk-s020.rsync.net or ssh-keyscan hk-s020.rsync.net and check if your version of ssh is picking up other keys?
19:09:24.195 Started a new SSH connection.
19:09:24.235 Connecting to SSH server usw-s003.rsync.net:22.
19:09:24.305 Connection established.
19:09:24.375 Server version: SSH-2.0-OpenSSH_8.2-hpn14v15 FreeBSD-openssh-portable-8.2.p1_1,1
19:09:24.375 First key exchange started. Cryptographic provider: Windows CNG (x86) with additions
19:09:24.535 Received host key from the server. Algorithm: Ed25519, size: 255 bits, SHA-256 fingerprint: jJCISHUXooV9/rh7kSeqiSuPvOVWBFCOe2CNkwTO46o.
19:09:24.555 First key exchange completed using Curve25519@libssh. Connection encryption and integrity: aes256-gcm, compression: none.
19:09:24.615 Attempting publickey authentication. Testing client key 'Profile 2' for acceptance.
19:09:24.726 The client key 'Profile 2' has been accepted.
19:09:24.726 Attempting publickey authentication. Signing with client key 'Profile 2'.
19:09:24.806 Authentication completed.
-t type
Specifies the type of the key to fetch from the scanned hosts.
The possible values are ``rsa1'' for protocol version 1 and
``dsa'', ``ecdsa'', ``ed25519'', or ``rsa'' for protocol version
2. Multiple values may be specified by separating them with com-
mas. The default is to fetch ``rsa'', ``ecdsa'', and ``ed25519''
keys.
Okay, so I guess we can use the dsa key for now. Although reading up on the topic, it looks like ssh-dsa is ideally supposed to be deprecated, with ed25519 as the new hotness.
Yeah; that's why ssh-keyscan didn't pick it up. Now why the Go ssh library decided that was the best cipher to pick, I dunno.
Maybe I'll create a PR to allow the cipher to be specified in the config file (since I think the library allows it). I'll stick it on my backlog of things to think about.
