-
Notifications
You must be signed in to change notification settings - Fork 671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSH Client fails handshake when using publickey method #1380
Comments
Out of curiosity can you post debug output on the |
Also have you tried different key types to try to isolate the problem? |
Below you can find the output of the debug log. I will try other authentication types (password and different key types) and let you know.
|
It looks like it is working as expected when using a key of type
And these are the debug logs of the server:
|
@mscdex as far as o understand the latest comment in the other issue (golang/go#66438 (comment)) the ssh2 library is doing something non-standard which is handled by OpenSSL client, but not by the go client. The go folks want to add this to their client as well. But maybe it is worth changing the ssh2 server component to be compatible with other clients still? For example, I have clients out in the wild which are compiled with the old version of the go library and are not able to connect. |
I did some more testing. I can confirm that my issue is fixed when using the proposed patch for the golang SSH client which accepts the algo returned by the ssh2 server. That's great. But as mentioned above, I'd love to have the server compatible with old versions of the golang client as well. So I did the following local change to the PKAuthContext class: @@ -144,11 +144,24 @@
accept() {
if (!this.signature) {
this._initialResponse = true;
- this._protocol.authPKOK(this.key.algo, this.key.data);
+ this._protocol.authPKOK(this.getResponseAlgo(), this.key.data);
} else {
AuthContext.prototype.accept.call(this);
}
}
+
+ getResponseAlgo() {
+ if (this.key.algo === 'ssh-rsa') {
+ switch (this.hashAlgo) {
+ case 'sha256':
+ return 'rsa-sha2-256';
+ case 'sha512':
+ return 'rsa-sha2-512';
+ }
+ }
+
+ return this.key.algo;
+ }
}
class HostbasedAuthContext extends AuthContext { It is not beautiful and most probably the mapping belongs somewhere else (either I'm not sure though whether this is really what the RFC requires (see this comment).
@mscdex can you please have a look at this? Happy to provide a PR if needed. |
@mscdex let me know if I can help in any way to get this fixed. |
Using MacOS Terminal.app I get the same. RSA keys don't work. ED25519 keys work. |
Also experiencing this. In my case, RSA keys don't work when connecting to Fedora Linux, but other key types work fine. All key types seem to work when connecting to Debian Linux. I'm using ssh2 version |
It turns out my issue was solved by changing the key bit length from 1024 to 2048. I used a small key since my use-case is just in a VM sandbox for testing purposes, but I guess some default configurations block RSA keys of small bit lengths |
I'm building a SSH server using your Node.js library and I'm building the SSH client using the x/crypto/ssh Golang library. The client aborts the SSH handshake when using the publickey authentication method.
I built an example project including server and client here: https://github.com/0x7f/ssh-authentication-bug
Even though the server offers [publickey] authentication methods when initiating the handshake with authentication method none, the client fails to connect. The client uses the publickey method and offers the key, and the server accepts the key, but the client still prints the error:
I'm trying to figure out whether this is a bug in the server library or the client library. I already posted a bug in the Golang project: golang/go#66438. Either the Node.js server library is doing something non-standard during the handshake, or the client has some issue, or I'm stupid and did something wrong in the code. The OpenSSH client works though.
Let me know when you need more information.
The text was updated successfully, but these errors were encountered: