Open Source Remote Access using VNC and Reverse SSH

Question

I am trying to get a remote access approach (open source) working involving openssh and tightvnc that deals with NAT, that allows someone to remote to my server and then allows me to vnc back to their machine w/o having to mess with their firewall and allows me to use a static WAN address down the road. I've been trying to rough this out in small steps to manage the unknowns (for me, a lot:). It would appear others have gotten this to work, but am stumped.

For starters, have have gotten passwordless reverse ssh working between two windows 10 virtual machines (hyperv) on my laptop (i.e., I'm not trying to deal with port forwarding on my firewall or the static WAN address yet) but can't get the vcn to work over the reverse ssh tunnel, though it works just using the lan IP address instead of "localhost" for the reverse ssh.

I am wondering if my overall approach is flawed or not. It is:

Machine A/Person A (wants help)
currently a win10 vm
ssh client (native on win10)
tightvnc server

Machine B/Person B (help desk role)
currently win10 vm (same LAN as machine A at present)
ssh server (optional win10 add on)
tightvnc client

The idea would be Person A on machine A starts the VNC server on machine A, and connects over reverse ssh to machine B (so far so good). At that point person B on Machine B could VNC back to machine A and help.

My assumption which may be the problem is to use reverse ssh from A->B (I've tried the -L option too instead of -R), and then use tightvnc to access machine A back from B. After starting the vnc server on machine A, an example of the initial ssh command I've gotten to work from A to B is:
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv

This part works. The vnc server on A has port 5902 (I have turned loopback on and off, tried listening server). I'm hoping this is something like I'm confused about which is the local host or something like that.

The error I'm getting on Machine B trying to vnc back to machine A over the ssh tunnel using "localhost::5902" is "connection has been gracefully closed". The vnc connection works if I just use the lanip of the vnc server on A from B.

There is nothing in the "tviewer.log" on either the client or the server. I've tried changing some settings in sshd_config (e.g., AllowAgentForwarding yes) with no result.

Q is my design flawed or workable? Is it the way I'm configuring things and can be addressed, possibly using a different ssh command?

Q do I need ssh server on both machines (am hoping to avoid this as means have to install it on other people's machines)?

I know there are various paid for and some free options to all of this, but am hoping to get it going.

Thank you.

Answer 1

We ran into something similar at work when dealing with SSH port forwarding on Windows. Have a look at the output of netstat, which confirms that TightVNC is listening on port 5901:

PS C:\WINDOWS\system32> netstat -an | findstr 5901
  TCP    0.0.0.0:5901         0.0.0.0:0              LISTENING
PS C:\WINDOWS\system32>

Contrast this with the listening sockets for the built-in Remote Desktop service (I've excluded the UDP sockets, which are unrelated to this discussion):

PS C:\WINDOWS\system32> netstat -an | findstr 3389 | findstr /V UDP
  TCP    0.0.0.0:3389         0.0.0.0:0              LISTENING
  TCP    [::]:3389            [::]:0                 LISTENING
PS C:\WINDOWS\system32>

The TightVNC service does not appear to implement dual-stack sockets (IPv4 + IPv6). This is unfortunate, because running the SSH client with a single -v will show the following messages when TightVNC attempts to connect backwards through the RemoteForward tunnel:

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 5901, originator 127.0.0.1 port 50132
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to localhost port 5900
debug1: channel 1: free: 127.0.0.1, nchannels 2

The line which matters is connect_next, which shows that the OpenSSH client is trying IPv6 and only IPv6 when proxying the connection.

I wasn't able to find any options in the TightVNC settings to bind IPv4+IPv6, but it doesn't matter because there is an easy workaround. Instead of this:

ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv

try this:

 ssh -R 5902:127.0.0.1:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv

To make matters more confusing, it is totally fine to enter localhost::5902 within the TightVNC client. That's because the OpenSSH listener on MachineB (port 5902) is dual-stack:

PS C:\WINDOWS\system32> netstat -an | findstr 5902
  TCP    127.0.0.1:5902         0.0.0.0:0              LISTENING
  TCP    [::1]:5902             [::]:0                 LISTENING
PS C:\WINDOWS\system32>

UPDATE: After reading back through your answer, I would like to verify that we are on the same page in terms of port numbers. The commands in my answer assume the following:

• Machine A -> TightVNC server -> Main server port = port 5901
• Machine A -> OpenSSH client -> RemoteForward specification = -R 5902:127.0.0.1:5901
• Machine B -> TightVNC client -> Remote Host = localhost::5902

In particular, I think you may have been running the TightVNC server on port 5902, despite the mismatch between this and the RemoteForward specification.

Answer 2

You mentioned that the VNC server on "Machine A" is running on port 5902 and you are also trying to connect to port 5902 (localhost:5902) on "Machine B" to get to "Machine A"'s VNC. The example you gave:

ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv

Is wrong. For what you're doing, you should be using:

ssh -R 5902:localhost:5902 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv

The 1st parameter to -R is the port that will be listened to by sshd on the remote (SSH server) side, while the 3rd parameter is the port that will be connected to by the SSH client on the local side, whenever someone connects to the 1st parameter port on the remote side. The way you describe it, you're wanting 5902 for both.

After you fix that, I don't see any reason why it wouldn't work.