Linux – How to release ports on the SSH server when a reverse ssh tunnel disconnects abruptly/uncleanly

If you set the 'LogLevel' in the sshd_config configuration file to DEBUG1 (or any DEBUG level), then sshd will log the port numbers in /var/log/auth.log.

Do remember, that using a LogLevel of DEBUG or higher could be a privacy risk, since much is logged.

(from /var/log/auth.log, removed a few lines to show relevant information)

Jun 24 06:18:24 radon sshd[9334]: Connection from 192.168.13.10 port 39193
Jun 24 06:18:24 radon sshd[9334]: Accepted publickey for lornix from 192.168.13.10 port 39193 ssh2
Jun 24 06:18:24 radon sshd[9334]: pam_unix(sshd:session): session opened for user lornix by (uid=0)
Jun 24 06:18:24 radon sshd[9334]: User child is on pid 9339
Jun 24 06:18:24 radon sshd[9339]: debug1: Local forwarding listening on 0.0.0.0 port 0.
Jun 24 06:18:24 radon sshd[9339]: debug1: Allocated listen port 39813
Jun 24 06:18:24 radon sshd[9339]: debug1: channel 0: new [port listener]
Jun 24 06:18:24 radon sshd[9339]: debug1: Local forwarding listening on :: port 39813.
Jun 24 06:18:24 radon sshd[9339]: debug1: channel 1: new [port listener]
Jun 24 06:18:27 radon sshd[9339]: Received disconnect from 192.168.13.10: 11: disconnected by user

If you follow it through, you can see where you could parse the connection information, and then the forwarded port (39813 in this case)

I used this command line between two of my machines, I do have ssh-key login set up, so no password prompts or delays

-xenon- lornix:~> ssh -R "*:0:radon:22" -N -T radon
Allocated port 39813 for remote forward to radon:22

-N specifies no command is given, and -T stops allocation of a tty for this connection.

Another way to disseminate the port connection information would be to parse it from the client side and send an email, jabber, text msg, smoke signals or pigeon to carry the port # to whomever needs it.

-R 8080:localhost:80 is usually not enough. See man 1 ssh [emphasis mine]:

-R [bind_address:]port:host:hostport
[…]

Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side.

[…]

By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address *, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).

Your tries with 127.0.0.1:8080 on the server indicate the listening socket is bound to the loopback interface. Most likely it is not bound to any other interface.

You need to explicitly specify bind_address or to use * or to use an empty string as bind_address. The option with an empty bind_address looks like this (note the leading :):

-R :8080:localhost:80

Additionally the state of GatewayPorts in the sshd_config on the server is important. From man 5 sshd_config:

GatewayPorts

Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be no to force remote port forwardings to be available to the local host only, yes to force remote port forwardings to bind to the wildcard address, or clientspecified to allow the client to select the address to which the forwarding is bound. The default is no.

To achieve what you want the option must not be no. Note no is the default value, so unspecified GatewayPorts still means no. The value of yes will make -R 8080:localhost:80 work like -R :8080:localhost:80.

I advise GatewayPorts clientspecified in the server config and ssh -R :8080:localhost:80 … on the client.

Possible additional problems:

• The firewall on the server may block connections to the 8080 port coming in from the Internet.
• The local HTTP server may reject requests that use example.com (compare Why does the original site work, but port forwarding to the same site fails?).