QUESTION: SSH Tunnel Connection Errors

[GrahamJenkins]

Details:
I have seen a lot of results about this connection error, for example in #1240. The two main issues people have been running into are:

• Enabling TCP Forwarding
• Certain RSA key types need to be accepted on the server

I believe I am having a different problem. I was previously using an Ubuntu client to connect to an Ubuntu server. Now I'm using a Debian client to connect to the same server and am unable to establish the tunnel within Beekeeper.

Version Information [might be relevant to your issue]
Operating System: Debian 12, freshly downloaded/installed last night
App Version [help -> about]: 4.1.13, downloaded from github and installed last night
Database type and version [eg Posgresql 9.3]: MariaDB Ver 15.1 Distrib 10.1.37-MariaDB, for Linux (x86_64) using readline 5.1

• Client key types: ed25519 (old and new keys)
• I have passwordless ssh keys installed and working
• Beekeeper says that it has found the SSH agent
• I can create a working tunnel manually (ssh -L10000:localhost:3306 servername) and connect to it directly
• Using a manual tunnel confirms that the database credentials are correct

Debug Console:
error watch null mysql tunnel.ts:49 tunnel/ GOT TUNNEL PORT 10000 tunnel.ts:57 tunnel config: {fromPort: 10000, toPort: 3306, toHost: 'localhost'} ConnectionInterface.vue?8c7e:81 error watch Error: Database Connection Error: SSH Tunnel Connection Error: All configured authentication methods failed at ov (client.ts:285:11) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async b.test (index.ts:321:69) mysql

Additionally, this looks like it could be related to mscdex/ssh2#352 however as mentioned above, I had a working tunnel under Ubuntu, I reinstalled with Debian and generated new ed25519 keys, now the new connection won't open.

I'm stumped. The best guess I have is that Beekeeper is incorrectly reporting a SSH agent, the agent isn't seeing the key, or that this is another compatibility issue with the SSH library used. For now I'll have to rely on manually creating SSH tunnels. If there are any other logs that can help I'd be happy to provide them. Any suggestions welcome, thanks!

[SimonSimCity]

I think I'm facing the same problem here. I have a database in Azure, which I try to access via an Azure Web App. Using the az webapp create-remote-connection command, I can create a remote connection using a tcp tunnel to my web app, which is then available at 127.0.0.1:9393 with the credentials { username: root, password: Docker! }.

Using the following command I can tunnel a connection to the database from localhost using the mentioned ssh host above as bastion:

ssh -L 5432:my-database.postgres.database.azure.com:5432 [email protected] -p 9393

And when using this port-forwarding, I can connect to the database as if it was a database running on my local machine. But I am unable to find the right settings of how to connect to the database without running the command above. I'd expect beekeeper to be able to create the tunnel for me, but I just keep getting is the error message - no matter what settings I set: SSH Tunnel Connection Error: Timed out while waiting for handshake.

I've been debugging https://github.com/beekeeper-studio/beekeeper-studio/blob/master/apps/studio/src/lib/db/tunnel.ts to get a glimse of how the ssh connection is set up. From what I've been able to debug, it seems that SSH connects correctly to the SSH tunnel service, but when trying to connect to the database, it seems to use the ssh-host as the hostname for the database 🤔 I'll see and let you know more.

[SimonSimCity]

Well ... it's not working using the published version 4.6.8, but when checking out the latest state of this repository, it works for me - so my bug seems to be fixed 😃🎉

@GrahamJenkins Do you have the chance to try if you can connect using a custom build?

.. as I'm writing this ... something made it work on my side now 😕 Don't know what it fixed, but I'll get back to debugging when I see it happen again.

EDIT:
I had it again and I could resolve it by clearing off my .ssh/known_hosts file 🙈