Ssh – Why SSH login works in shell but fails in all third parties via ssh tunnel

sshssh-tunneling

I'm using ssh to log in (prompt password first time) on a remote server.

In shell, using this command:

ssh root@myserver.com

works well! But all other db software applications that I tested (Dbeaver and Redis Desktop Manager) fail when I try to use SSH Tunnel. I selected my private key from /home/myuser/.ssh/id_dsa.

Example in Redis Desktop Manager:
rdm

Example in Dbeaver:
enter image description here

If I set the tunnel:

ssh root@myserver.com -L 6379:127.0.0.1:6379 -N

I can connect to 127.0.0.1:6379, i.e., the tunnel is working.
Why via third party is this not working?

In remote server is running CentOS 6 and in my desktop Ubuntu 14.

Best Answer

You said, in the comments,

After restarting my computer, when trying to login via ssh again, I was asked the password to unlock the id_dsa file

There's at least part of the answer. Your other tools have no ability to unlock a private key, and no ability to talk to ssh-agent to have it authenticate on their behalf. You need to remove the password from the private certificate.

The syntax is:

ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

And as you pointed out in your comment, the practical application of this is:

ssh-keygen -p -f ~/.ssh/id_dsa

The next part of the problem is that some third-party libraries for Java and .NET will only handle RSA ssh keys - and (in my experience) only up to a certainly key length. DSA and ECDSA are not options.

If you don't have ~/.ssh/id_rsa then you are going to need to create it, and copy the public part to the remote host:

ssh-keygen -t rsa
ssh remoteuser@remotehost 'cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub

Another part of the problem may be that the private key is in the "wrong" format and needs conversion. From a brief perusal of the documentation for Redis Desktop Manager I don't believe this is the case but it would be worth double-checking. UPDATE: It appears that JSCH - Invalid private key confirms that the key is expected to be in OpenSSH format - which is what it appears you are already using.

Related Solutions

Remote Desktop – Use KDE Over SSH Reverse Tunnel

If you are using a server-in-the-middle to interconnect two systems, chances are at least one of the lines is rather slow. In that case VNC is likely to give you better performance, since you can tune the bandwidth/performance requiremens/quality ratios better (this is actually valid for most setups, unless you are on a reliable 100Mbit+ network).

I personally like x11vnc, which connects to a running X server and forwards the inputs/output over the VNC protocol (this can be done as soon the X server is running, so you can interact even with a display manager). The X server in question can be both a regular one (which outputs to a real display) or a framebuffer based one like Xvfb. You can then use any VNC client to connect to the exported X server. And of course you probably want to tunnel the transmissionn through ssh or stunnel. The man page of x11vnc is quite exhaustive and even has a frequently used command line example at the beginning.

Ths also allows you to remotely connect to a running session to help somebody solve a problem remotely. As an important bonus, since just the inputs and output are forwarded rather than the X protocol itself, network disconnects will just interrupt the session, but all of the programs remain running, which is not the case of X through SSH.

If for some reason you really want to tunnel X11 through SSH, you must ensure that the DISPLAY environment variable is set up properly by ssh. Without it you can't proceed, because the applications won't know which server to connect to. Check whether the X11Forwarding directive is set to yes in your sshd configuration.

Last but not the least, you probably don't want to run startkde4 (or any other X session for that matter) over SSH - the network load will likely be quite heavy - VNC will serve you better again.

SFTP – How to Use SFTP Over Reverse SSH Tunnel

First, this is a prerequesite (at least for me): Remote desktop over SSH reverse tunnel to replace TeamViewer

The reverse SSH tunnel looks like this:

laptop(SFTP client)--->nat--->middleman<--nat<--desktop(SFTP server)

On laptop edit ~/.ssh/config and add this:

Host SftpToDesktop
  HostName localhost
  Port %p
  User admin
  PasswordAuthentication no
  IdentityFile ~/.ssh/my_id_rsa

Then, with an existing SSH leg from laptop to middleman established already (as per above link), do the following:

$ ssh -fNL 1234:localhost:1234 -i ~/.ssh/some_id_rsa admin@middleman.com

Finally, open Dolphin (if using KDE like me) and enter this location:

sftp://SftpToDesktop:1234

Best Answer

Related Solutions

Remote Desktop – Use KDE Over SSH Reverse Tunnel

SFTP – How to Use SFTP Over Reverse SSH Tunnel

Related Question