With cygwin, how do you restart an ssh reverse tunnel without a forwarding issue "Warning: remote port forwarding failed" message occurring?

Question

With cygwin, how do you restart an ssh reverse tunnel without a forwarding problem "Warning: remote port forwarding failed" message occurring?

I have this command ssh -R 50500:127.0.0.1:5900 user@myip and it logs me into my ssh server.

The idea is I have a computer I want to view, and a computer that is the viewer. And the computer myip, is the intermediary, a hosted VPS.

So the viewed runs the command viewed$ ssh -R 50500:127.0.0.1:5900 user@myip<ENTER>

And the viewer runs the command viewer$ ssh -L 1234:127.0.0.1:50500 user@myip<ENTER>

And then from the viewer computer, I connect VNC viewer to 127.0.0.1:1234

And it all runs well.

Until something happens and VNC won't connect. I have driven away the viewed computer so I can't see the screen, but I take a guess what a possible cause might be. The internet connection at the viewed machine is poor, there's no landline, so I have a router with a mobile SIM card in there. And I have a feeling that maybe the connection breaks from time to time.

So what I tried was this

$ while true; do ssh -R 50500:127.0.0.1:5900 user@myip; done

If I try it, it works, then I go home, and it might still work. But eventually, it doesn't work.. so it's possible that line helped a bit, but I still face a similar issue of VNC connecting for a while, and then not connecting.

So I drive up to the location of the viewed computer, and I look at the viewed computer. And I see some messages like this

user@vps:~# client_loop: send disconnect: Connection reset by peer
Warning: remote port forwarding failed for listen port 50500
Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-113-generic x86_64)
...
*** System restart required ***
Last Login...

The word "loop", in "client_loop: send disconnect: Connection reset by peer" is no mystery. The Tight VNC Viewer is doing 127.0.0.1:1234 to ultimately connect to the TightVNC server, and that's fine.

But now I have an idea why VNC won't connect. It won't work because the command on the viewed computer needs to run without that "warning" error / the cause of that "warning" error!!

When the VNC connection doesn't go through, it's because the forwarding isn't working on the "viewed" side. That's a serious problem!

I'm wondering if maybe it's because the connection is flaky, and doesn't fully disconnect when the connection breaks momentarily.

What can I do to deal with the cause of that "warning" error and connect?

I'm not sure if it's an SSH -L that is failing or an SSH -R, or both. Though I think it's probably an SSH -R that is failing 'cos that message about the error in forwarding, comes up on(in the cygwin window /console of), the viewed computer.

Answer 1

I figured that if I can kill an unwanted established connection it could help.

And this can be done here as I that each connection has its own SSHD process.

I can't see which connections are SSH -L or SSH -R.

The SSH -R is command creates the connection that I have an issue with.

I want to be ending the processes, ssh and sshd, of that connection.

The command netstat -atnp shows the connections, PIDs and process names.

The SSH -R command creates two listings on netstat, -atnp, one to port 22, the other is to listen on port 50500. I may have other connections on port 22. But if I kill the PID associated with listening on port 50500, it breaks the connection associated with SSH -R by killing the sshd process associated with it.

From the SSH server.

user@comp:~# netstat -atpn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:50500         0.0.0.0:*               LISTEN      199414/sshd: root
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      592/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      196970/sshd: /usr/s
tcp        0      0 164.....:22        213.....:52504   ESTABLISHED 199414/sshd: root
tcp        0      0 164.....:22        213......:43830   ESTABLISHED 198992/sshd: root@p
..
user@server:~#

The command $kill -9 199414 will break that SSH -R connection. (no need to kill more processes than that so no need to list other PIDs after that)

To ensure though that both sshd and ssh of that connection are killed..

I have these lines in my /etc/sshd/sshd_config file

user@server:~# grep -i client /etc/ssh/sshd_config
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 10
ClientAliveCountMax 1
# Allow client to pass locale environment variables
user@server:~#

So every 10 seconds sshd will check if the client is there and if not then it will disconnect. This should deal well with the possibility that the client's IP changes!

And I have these lines on my client side, `/etc/ssh_config, the computer doing the SSH -R

$cat /etc/ssh_config ...

ServerAliveInterval 10
ServerAliveCountMax 1

So every 10 seconds it'll send one signal to the server and if the server is down then the ssh client should exit.

I also have this SSH -R command on the client

$ while true; do echo abc && date && python logtheip.py && ssh -N -R 50500:127.0.0.1:5900 root@164.... ;done

The code for logtheip.py is something like what this person has https://gist.github.com/giammin/d174c0db2b39dcf2ba68f8b3df02f4f9 that I got from https://unix.stackexchange.com/questions/277703/how-to-track-my-public-ip-address-in-a-log-file That writes the IP to a log file along with the date/time.

The echo before the ssh -R shows me that the ssh executable has exited and the loop has iterated.