SSH (with SSHJ) does work for all servers except one

[foobar13372]

I'm using Ubuntu 21.10 with DBeaver 22.0.3.

I have mutliple SSH profiles configured, all using the bundled SSHJ with the exact same connection settings. The only difference is the hostname, port and username, of course. All use the same private key, of this format: -----BEGIN RSA PRIVATE KEY-----

However, on one single of these connections I get the error Exhausted available authentication methods. This connection does work on the shell via ssh connection-name, however!

If I open the general settings (last entry in main menu "Window") and there go to Connections -> SSH2, then the known hosts tab does not list the server in question, but it actually is in the known_hosts file (that's why it works from the shell)!

The only difference I see between the lines in known_hosts file is this: the working/DBeaver-listed ones use ssh-rsa and the not-working/not-listed one uses ssh-ed25519 as encryption algorithm. But this is determined by the foreign server and out of my control, AFAIK (because this is the key algorithm used by the server key).

Is this a bug or do I somehow have to enable SSHJ/DBeaver to be able to handle the ed25519 algorithm from the known_hosts file?

[foobar13372]

Ah, I added a new private key for my user, using ed25519. Now it works also in DBeaver.

So, I think the bug actually is: a SSH connection from DBeaver does only work if client and server use the same key algorithm, But this is clearly a bug, possibly of SSHJ.

In assymetric encryption it's totally valid that both directions use different algorithms. The client encrypts with the server pubkey algorithm, the server with the client pubkey algorithm. Requring both to be the same is a bug.

[ShadelessFox]

Hello @foobar13372,

Your issue seems to be similar to #4013. It was closed because it was stated that SSHJ now supports this type of an elliptic curve.

However, the version of the SSHJ that we package is quite outdated (0.27.0), we need to upgrade it to the latest version (0.32.0).

[skotos]

Please consider SSHJ 0.33.0 as I believe they have finally allowed for better detection of ssh-rsa2 when openssh is not using ssh-rsa.

• hierynomus/sshj@d7e402c (0.33.0 Release Notes):
  • Lean on Config.keyAlgorithms choosing between rsa-sha2-* and ssh-rsa hierynomus/sshj#742

[uslss]

@foobar13372 fix is already available in EA version. Could you check if it is ok?

[skotos]

Unfortunately I'm still receiving "Can't initialize tunnel -> Cannot establish tunnel -> Exhausted available authentication methods"

Confirming that this is happening with the following:

• dbeaver - 22.0.5
• org.jkiss.dbeaver.net.ssh.sshj - 1.0.103.202205120849
• org.jkiss.bundle.sshj - 0.33.0.

This error does not occur if I add the following lines to the servers sshd_config (i.e. re-allow depreciated key type.)

PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa

[ShadelessFox]

Hello @skotos,

It's sad to hear that.

I'm a little bit confused now. Is the issue actual for ssh-ed25519 or ssh-rsa?

[skotos]

At the moment I'm using rsa-sha2-512. Using normal ssh command from the command line I get:

May 17 10:22:27 sqlsvr sshd[17520]: debug1: userauth-request for user scott service ssh-connection method publickey [preauth]
May 17 10:22:27 sqlsvr sshd[17520]: debug1: attempt 1 failures 0 [preauth]
May 17 10:22:27 sqlsvr sshd[17520]: debug1: userauth_pubkey: test pkalg rsa-sha2-512 pkblob RSA SHA256:d.........................................4 [preauth]

but using dbeaver:

May 17 10:21:55 sqlsvr sshd[17515]: debug1: userauth-request for user scott service ssh-connection method publickey [preauth]
May 17 10:21:55 sqlsvr sshd[17515]: debug1: attempt 0 failures 0 [preauth]
...
May 17 10:21:55 sqlsvr sshd[17515]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

For now, I'll key up an ed25519 for dbeaver work as that seems to work ok.

[ShadelessFox]

Using the rsa-sha2-512 key, I was able to authenticate.

Unfortunately, I don't have a lot of experience with SSH. Therefore, I'm unable to help you, sorry.

[ShadelessFox]

@foobar13372,

Could you please download the latest EA version and see if the issue is gone there?

[skotos]

Not sure the EA version had changed. (Still dated 2022-05-12 11:28:05) Re-downloaded it just in case and still the same issue with rsa-sha2-512 key.

A bit of background. This is happening with openssh-8.8 server having the following PubkeyAccepted Algos (sshd -T):

pubkeyacceptedalgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256

As soon as rsa-sha is added to the algos (see comment on 13 May), it succeeds, even though the pubkey is rsa-sha2-512. I think SSHJ is relabelling the algo as simply rsa-sha.

I have now bumped over to an ed25519 key now, so the issue no longer affects me, (though I can still test with rsa-sha2-512 if you'd like.)

[krilim]

Hi, the same happen to me.

I can connect with an ed_25519 key using console ssh (MacOS and Fedora 36) but I cannot do the same with dbeaver using same credentials with SSHJ.

I have other connections with the same ed_25519 key and they work without problems.

Version is 22.0.5 with MacOS 12.4 and/or Fedora 36

Both remote machines are CentOS 7 (the one that works and the one that does not)

[camlafit]

Hello

I think I'm in same trouble as explained before.
I've tried to connect over ssh with ed25519 and get this error :

Unable to reach a settlement of Client2ServerMACAlgorithms: [hmac-sha1, [email protected], hmac-sha1-96, [email protected], hmac-md5, [email protected], hmac-md5-96, [email protected], hmac-sha2-256, [email protected], hmac-sha2-512, [email protected], hmac-ripemd160, [email protected], hmac-ripemd160-96, [email protected]] and [[email protected]]

I've tried with SSHj and JSch implementation. I'm up to date to now (Version 22.2.5.202211202223)

With terminal and same key with(out) agent It's ok.