20
4
We have a some hardware we install at our customers' locations, that hardware connects to our ssh server and establishes a reverse ssh tunnel so we can gain access to several client systems for monitoring purposes.
Everything works fine until there is an unclean disconnect of the SSH session.
When that happens, on our SSH server the ports that were used by the reverse tunnel stay stuck in LISTENING mode and when our remote hardware eventually tries to auto reconnect and re-establish its tunnels it fails with the error
Warning: remote port forwarding failed for listen port XXXX
I tested if there was an issue with our SSH server or client by trying a clean disconnect and course that releases the ports just fine. When I simulate a connection failure (disconnect the Ethernet port of the client hardware for example) then we have the same issue I described above.
What is the proper way of handling this situation? Keep in mind these are reversed tunnels so whatever happens needs to be done on the SSH server. Ideally i need the ssh server to realize instantly that the SSH session hosting the tunnels is down and release the ports it was using. I guess the solution could involve killing the concerned SSH process but I need to be careful with that cause we have multiple clients connecting to the same ssh server and I wouldn't want to kick them offline.
Being so mature, I'm sure SSHD has some sort of built in feature to handle this but I just can't figure it out.
Please advise so I don't have to go back to administering Windows boxes ...
FYI: I'm running this on a Debian based distro.
1I have already implemented this exact solution, to the exactly same problem. However, I sometimes still find a connection that is in LISTEN state on the server, even though according to the logs on the client, the client already terminated the SSH tunnel executable after detecting a timeout (with ServerAliveInterval/ServerAliveCountMax). Most of the times it works as expected and the configuration seems good. But in rare cases, I encounter a connection which stays in the LISTEN state. I know it shouldn't be possible, is it a bug, or am I missing a case in which this solution does not work? – Yeti – 2020-01-26T07:34:39.583
1
In continuation of my previous comment, this is a related question without any answers, and this and this bug reports describe a similar problem, again without any answers. Even while also this answer proposes the same solution for this use-case, as a solution that ought to work, but doesn't
– Yeti – 2020-01-26T07:45:34.940Thank you Clement. I will look into setting that up on our server. – TCZ – 2014-04-21T20:12:52.377
Done and tested, works beautifully. Thank you very much. – TCZ – 2014-04-21T20:55:18.223