Remote desktop over SSH reverse tunnel to replace TeamViewer

Question

I want to open a remote desktop session from my laptop to desktop over my SSH (reverse) tunnel. That should be simple (or at least doable), right? Until now I've been using Team Viewer to log in to the remote desktop. I'd like to achieve similar results without Team Viewer.

Here's what my SSH tunnel looks like:

laptop--->nat--->middleman<--nat<--desktop

All machines are running Linux (mostly Kubuntu 12.04 or OpenSuse 12.3). I cannot change any ports or make any configuration changes on the nat routers.

I'll describe my SSH tunnel because understanding that appears to be necessary in solving the VNC / remote desktop issue that is the heart of my question. Regarding this leg:

middleman<--nat<--desktop

...here is how it is established:

autossh -M 5234 -N -f -R 1234:localhost:22 [email protected]

Regarding this leg:

laptop--->nat--->middleman

I can connect to middleman as follows:

me@laptop:~$ ssh -i ~/.ssh/id_rsa admin@middleman  

However, what I actually need to do is connect directly to the desktop, not to the middleman. To do that I use netcat ("nc") on middleman. Based on this it appears that nc is required. So I edit my SSH config file on laptop to use ProxyCommand and nc:

me@laptop:~/.ssh$ nano config

The contents are:

Host family_desktops
  ProxyCommand ssh middleman_fqdn nc localhost %p
  User admin
  PasswordAuthentication no
  IdentityFile ~/.ssh/my_id_rsa

Where middleman_fqdn is like "middleman.com"

Then I just connect to "desktop" in one step:

me@laptop:~$ ssh family_desktops -p 1234

(I got this working based on help here and here and other related questions I asked. I have asked a ton of questions on this topic because I have been wresting with it for many weeks.)

With this SSH connection I reach a fully functioning shell on my computer labeled desktop. Perfect.

Now I just need a VNC-like (or TeamViewer-like) remote desktop solution over this SSH tunnel. How?

Here is what I have tried so far:

middleman<--nat<--desktop

autossh -M 5235 -N -f -R 1235:localhost:5901 [email protected]

with that connection established:

x11vnc -autoport 5901 

I watch to make sure it connects to port 5901, which it does.

laptop--->nat--->middleman<--nat<--desktop

laptop ~/.ssh/config:

Host family_desktops
  ProxyCommand ssh -NL 5901:localhost:1235 middleman.com nc localhost 1235
  User admin
  PasswordAuthentication no
  IdentityFile ~/.ssh/my_id_rsa

Tunnel setup:

me@laptop:~$ sudo ssh family_desktops

VNC client:

connect to localhost:5901

This gives an error of "server not found"

I have tried a number of variations on the ProxyCommand, none of them successful. Obviously, I'm guessing about which parameters should be in ProxyCommand and which should be on the ssh command line. I can see some potential problems with my setup, but I haven't been able to figure out what will make it all work.

P.S. As mentioned, I have asked several questions about this. Some of those led me closer to the solution and form the basis of my present question. Other of my prior questions on this topic just show my ignorance and inability to ask the question in the right form. At this point, this present question represents my best ability to state what my problem is and what my desired solution is, but some of my other questions are still open too. Here's one that is relevant.

Answer 1

Can you try doing the second step without doing the nc? That is - do the VNC with just the -L and -R. I believe the issue is that your netcat session is connecting back to an already open. So when doing the VNC stuff don't use netcat.

Answer 2

Instead of ProxyCommand, you should set "gatewayports yes" for your middleman sshd.conf.

1. Then take remote tunnel from desktop to middleman and opening the tcp port x in middleman and vnc on local.
2. Then take local tunnel from laptop to middleman opening vnc port to you localhost and tunneling it to x.
3. Then connect to localhost:vnc, so it will go via local tunnel to middleman and remote tunnel to laptops vnc.

After you get it working, learn more about more secure settings of gatewayports.