Open StevenSchoch opened 2 years ago
I'm seeing the same issue.
This article about ssh-rsa deprecation helps explain this issue. In the context of SSH public key signature, the algorithm "ssh-rsa" uses RSA and SHA-1. Because the SHA-1 algorithm was broken in 2017, it is no longer accepted as a way to send SSH public key signatures as of OpenSSH 8.8.
Instead, the more secure algorithms, which use SHA-2, are used instead. These include rsa-ssh2-256 and rsa-ssh2-512.
Newer SSH clients, such as Putty 0.76, have support for these algorithms. Older SSH clients, such as Putty 0.74 and vscode-sftp, do not support these. This can be seen from the debug output:
[02-04 12:10:49] [debug] Handshake: (local) Host key format: ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
[02-04 12:10:49] [debug] Handshake: (remote) Host key format: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
[02-04 12:10:49] [debug] Handshake: Host key format: ssh-rsa
The very confusing part is that these algorithms are used in both the SSH host key verification (which identifies the SSH server to which the client is connecting), and the public key signature, which is used for private key authentication. OpenSSH 8.8 disabled the use of ssh-rsa for public key signatures, but still have it available for host key verification, because otherwise many old SSH clients wouldn't be able to connect. Using the broken SHA-1 algorithm to verify the host key is not a big security issue, because it can't be used by an attacker against a SSH server. This means that the ssh-rsa algorithm is still offered as a host key format, but if the client offers a public key with that algorithm, the server declines it, as if that public key was not in the authorized_keys file.
The solution is to add the rsa-sha2-512 algorithm to vscode-sftp.
I suppose if I could create an ECDSA public key, then the ecdsa-sha2-nist256 algorithm could be used. I'll have to look into that.
Update: Using an ECDSA key worked.
@StevenSchoch, @Christoph142, This should be fixed in pull-request #119.
You can test it by downloading or updating to the latest version of the extension available here. 😉
Please tell me if it works fine now.
Hi, I'm hitting the same issue, with a new server running OpenSSH 8.9.
I am able to connect using command line sftp, so it seems like it should work with the extension.
With the extension I just get the error: "Error: [ip address]: All configured authentication methods failed". I have checked and re-checked the config, it's correct. Is there anything else I can try?
Forgot to mention I'm running v1.15.14 of SFTP
please check that if you're using ssh private+public key combo that you've correctly added your local public key to your .ssh/authorized_keys
file on your server.
@Natizyskunk Yes, I regularly ssh into the server via public key, so I know that is set up correctly.
Doesn't seem to work for me either. Tried to add the algorithms mentioned in the fix, but that didn't seem to work. Using an ECDSA key pair did. The RSA key does work for putty though. Connecting to the ssh server for this project: https://github.com/hassio-addons/addon-ssh.
Please update your sftp extension to the latest version and try this config then let me know if it worked.
{
"useTempFile": true,
"openSsh": true, // <-- you can also try with false but keep in mind that if you set it to true, `useTempFile` must also be set to true.
"algorithms": {
"kex": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256" // <-- this can keep closing the connection for those who use more legacy/old systems problem so please also try without it !
],
"cipher": [
"aes128-gcm",
"aes128-gcm@openssh.com",
"aes256-gcm",
"aes256-gcm@openssh.com",
"aes128-cbc",
"aes192-cbc",
"aes256-cbc",
"aes128-ctr",
"aes192-ctr",
"aes256-ctr"
],
"serverHostKey": [
"ssh-rsa",
"ssh-dss",
"ssh-ed25519",
"ecdsa-sha2-nistp256",
"ecdsa-sha2-nistp384",
"ecdsa-sha2-nistp521",
"rsa-sha2-256",
"rsa-sha2-512"
],
"hmac": [
"hmac-sha2-256",
"hmac-sha2-512"
]
}
}
I'll try to take a further look when i've more time.
When you say latest version, do you mean 1.15.19? That is the latest I can find... tried augmenting my config with what you have above, in various combinations with openSsh
set to both true and false and diffie-hellman-group-exchange-sha256
included and excluded, but no luck.
@inorganik, I'm sorry to hear that. I'll keep an eye on this issue and I'll let everyone know if a fix is found.
@Natizyskunk no worries. On the bright side, I've found using the sftp CLI is pretty painless.
Similar to @peter-vanpoucke I was able to get this working by creating a new key pair using the EdDSA algorithm instead or RSA.
Our web server (pair.com) recently (a few months ago) upgraded their SSH server to OpenSSH 8.8. This caused private keys sent from older SSH clients to fail. When using a private key (via ssh-agent), vscode-sftp fails with "All configured authentication methods failed."
Connecting with the same private key to an OpenSSH 8.0 system works from vscode-sftp. Connecting with the same private key to the OpenSSH 8.8 system works from ssh on MacOS.
This same issue with vscode-sftp also occurs with Putty 0.74, but is fixed with Putty 0.76.
In summary, using an SSH private key to authenticate:
vscode-sftp -> OpenSSH 8.0 works. vscode-sftp -> OpenSSH 8.8 fails. MacOS command-line ssh -> OpenSSL 8.8 (and 8.0) works. Putty 0.74 -> OpenSSH 8.0 works. Putty 0.74 -> OpenSSH 8.8 fails. Putty 0.76 -> OpenSSHl 8.8 (and 8.0) works.
The reason I mention Putty is that the problem was fixed in the protocol change they made from 0.74 to 0.75. In order to fix the problem with vscode-sftp, the same change may be required.
Using VSCode version 1.63.2 OS: MacOS High Sierra version 10.13.6 vscode-sftp version: 1.15.10
Logs: