Authentication with public key fails with 0.1.62

[avnerw74]

Hi,

We were using 0.1.55 to connect to a server using public key auth without a problem.
After we upgraded to 0.1.62, public key authentication fails with "Auth Fail".
If we use the UserAuthPublicKey class from 0.1.55, we are able to login again.

Is this a known bug?

Thanks,
Avner

[mwiede]

Hi Avner,
I guess that you have the same issue like the guys in #37 or #40

The reason is, that configured algorithms is changed in 0.1.62 for security reasons. They are aligned with recent openssh versions.

So you might have to change the config like
Session session = Jsch.getSession(username, host) session.setConfig("kex", "<yourkeyalgo>"); or kex
or
session.setConfig("cipher.c2s", session.getConfig("cipher.c2s") + ",aes128-cbc"); session.setConfig("cipher.s2c", session.getConfig("cipher.s2c") + ",aes128-cbc");
for ciphers.

I will update the readme soon, since it is important to understand this change when using this library as a replacement of Jsch.

Kind regards
Matthias

[ihudedi]

Hi @mwiede
We do change the ciphers and in kex as well as you wrote above but the authentication failed when using public key.
When using password it works fine.
If I use the UserAuthPublicKey file form version 1.55 the public key authentication succeeded OK.
Thanks,
Itay

[norrisjeremy]

Hi Avner & Itay,

A few questions:

1. Are you able to add a JSch logger and capture debug logging from when it fails with 0.1.62?
2. Is the public key you are using encrypted with a passphrase or is it unencrypted?
3. Do you know what the type and version of the SSH server you are connecting with?
4. Are you able to narrow down which particular release between 0.1.55 and 0.1.62 the problems with the UserAuthPublicKey class started?

Thanks,
Jeremy

[norrisjeremy]

Also, if you can run the following nmap command against the server in question, it can help provide details as to what SSH version it is and what crypto algorithms it supports:

nmap --script ssh2-enum-algos -sV -p <PORT_OF_SERVER> <IP_ADDRESS_OF_SERVER>

[ihudedi]

Hi @mwiede @avnerw74

1. I am able to capture debug log via Jsch logger.
2. We are using public key authentication with passphrase
3. Remote version string: SSH-2.0-CerberusFTPServer_9.0
4. It is also working in 1.56.from version 1.57 to 1.62 it's not working.
5. We use cerberos server on windows machine therfore can't run the nmap command.

Thanks,
Itay

[norrisjeremy]

Hi Itay,

1. Can you provide the debug logs here?
2. You don't need to execute the nmap command on the Windows server that hosts the Cerberus server, but rather you just need to execute the command from a machine that is able to open TCP connections to the Cerberus server (such as your workstation or the server running your JSch application). Do you think that would be possible (since it will help to quickly identify what crypto algorithms the Cerberus server is advertising for use).

Thanks,
Jeremy

[norrisjeremy]

Hi Itay,

Can you confirm if 0.1.62 works if you add this statement before you initiate any sessions?

JSch.setConfig("PubkeyAcceptedKeyTypes", "ssh-rsa," + JSch.getConfig("PubkeyAcceptedKeyTypes"));

Thanks,
Jeremy

[ihudedi]

Hi @norrisjeremy
Adding ssh-rsa as first in PubkeyAcceptedKeyTypes solved the issue but I have another question:
In jsch 1.55
kex=ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
Mac=hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
Signatures=ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
CheckCiphers=aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
CheckKexes=diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
CheckMacs=
CheckSignatures=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

But in jsch 1.62 the values are:
Kex=curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
Mac=hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Signatures=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
PubkeyAcceptedKeyTypes=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
CheckCiphers=chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
CheckKexes=curve25519-sha256,curve25519-sha256@libssh.org,curve448-sha512,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
CheckMacs=hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
CheckSignatures=rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-ed448

I understand that you changed the order of the values for better security but it cause performance issues when trying to connect.
For example the kex curve25519-sha256 is new and you trying to check for this while in older version it wasn't.
same for all other params.
I saw that pubkeyAcceptedKeyTypes wasn't in jsch 1.55 and in jsch 1.62 it;s the same value as signature so I modified the value in my code to be as signature=ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

Maybe it's worth to add them as optional not the first because it takes 3-10 seconds to check if kex is correct or bot for this version,
Thanks,
Itay

[ihudedi]

Hi @norrisjeremy
In case the ssh-rsa isn't the first in PubkeyAcceptedKeyTypes - the public key authentication failed.
Will you fix this issue?
Currently I modifed the pubkeyAcceptedKeyTypes to be signatures as defined as in jsch 1.55
ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
Thanks,
Itay

[norrisjeremy]

HI Itay,

The discussion in #45 provides more details as the default values of PubkeyAcceptedKeyTypes.

Thanks,
Jeremy

[norrisjeremy]

I understand that you changed the order of the values for better security but it cause performance issues when trying to connect.
For example the kex curve25519-sha256 is new and you trying to check for this while in older version it wasn't.
same for all other params.
I saw that pubkeyAcceptedKeyTypes wasn't in jsch 1.55 and in jsch 1.62 it;s the same value as signature so I modified the value in my code to be as signature=ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

Maybe it's worth to add them as optional not the first because it takes 3-10 seconds to check if kex is correct or bot for this version,
Thanks,
Itay

Hi Itay,

With regards to your comment above that you are seeing it take 3-10 seconds to check if the kex is correct: I don't see that behavior locally. Can you provide more details with regards to the environment in which you see this behavior (operating system, Java version, etc.)?

Thanks,
Jeremy

[ihudedi]

Hi @norrisjeremy @avnerw74
I didn't understand what is the solution in #45
In case I don't set the pubkeyAcceptedKeyTypes and insert ssh-rsa as first I can't connect with publicKey.
Thanks,
Itay

[norrisjeremy]

Hi Itay,

See the comment:
#45 (comment)

The server you are connecting with most likely enforces a MaxAuthTries setting of 2 or less:

"My suspicion as to what is happening is that the OpenSSH 5.3 server you are attempting to connect with has MaxAuthTries configured to a small value (2 or less). Combined with the fact that the default PubkeyAcceptedKeyTypes attempts to use the RSA SHA-2 signature types (rsa-sha2-256 & rsa-sha2-512) before the legacy RSA SHA-1 signature type (ssh-rsa), this causes authentication to fail. This is due to the fact that the client signature type is not actually negotiated in the SSH protocol: the client simply has to brute force attempt each one in succession until it succeeds, or the server rejects the connection for Too many authentication failures. And since RSA SHA-2 signature types weren't introduced until OpenSSH 7.2, JSch is attempting to use first rsa-sha2-512 (which fails), then rsa-sha2-256 (which fails), and before it can try ssh-rsa (which would succeed), the server terminates the session because of it's MaxAuthTries setting."

By putting ssh-rsa at the start of the PubkeyAcceptedKeyTypes setting in JSch, this causes it to attempt to use it it before rsa-sha2-512 and rsa-sha2-256 (which I suspect the server you are connecting to does not support).

Thanks,
Jeremy

[norrisjeremy]

Hi @ihudedi,

Did you have an opportunity to review the last comment I left?
Additionally we have made some changes in the recent 0.1.65 release to help. See #59 (comment) for more details.

Thanks,
Jeremy

[MartinTello]

Hi Itay,

See the comment: #45 (comment)

The server you are connecting with most likely enforces a MaxAuthTries setting of 2 or less:

"My suspicion as to what is happening is that the OpenSSH 5.3 server you are attempting to connect with has MaxAuthTries configured to a small value (2 or less). Combined with the fact that the default PubkeyAcceptedKeyTypes attempts to use the RSA SHA-2 signature types (rsa-sha2-256 & rsa-sha2-512) before the legacy RSA SHA-1 signature type (ssh-rsa), this causes authentication to fail. This is due to the fact that the client signature type is not actually negotiated in the SSH protocol: the client simply has to brute force attempt each one in succession until it succeeds, or the server rejects the connection for Too many authentication failures. And since RSA SHA-2 signature types weren't introduced until OpenSSH 7.2, JSch is attempting to use first rsa-sha2-512 (which fails), then rsa-sha2-256 (which fails), and before it can try ssh-rsa (which would succeed), the server terminates the session because of it's MaxAuthTries setting."

By putting ssh-rsa at the start of the PubkeyAcceptedKeyTypes setting in JSch, this causes it to attempt to use it it before rsa-sha2-512 and rsa-sha2-256 (which I suspect the server you are connecting to does not support).

Thanks, Jeremy

I was having problems trying to connect to azure ( Remote version string: SSH-2.0-AzureSSH_1.0.0). I solved rearranging the "PubkeyAcceptedKeyTypes" putting first the rsa-sha2-256.
So I assume that the problem was the MaxAuthTries .