Reverse Tunneling with SSH

Like most people, you’ve probably experienced using a shared internet connection without (legal) access to its administration panel. Think back to student housing—college dorms, apartments, or homes rented by the room, all with shared WiFi and common areas. While restrictive network setups help protect users, they severely limit your options, particularly if you want to host services like a personal website that should be reachable outside your local network.

In situations involving restrictive firewalls or NAT setups on IPv4, external traffic (the WAN) sees only the gateway’s IP—not the individual devices within the network. Without admin access to configure incoming data routes, it becomes a major hurdle: how can external users find your device if everything is hidden behind a single public IP?

To verify this, you can check your external IP with a service like whatismyip.com from multiple devices, or run this command:

curl -L https://www.wtfismyip.com/text | tee IP.ADDR

This displays your external address in the terminal while also writing it to a file named IP.ADDR. Unless you’re using a VPN or proxy, each device will show the same external IPv4. A traceroute will typically reveal it’s a single hop away, indicating the gateway belongs to your ISP.

When it comes to outgoing data, this really poses no issue from a functional standpoint. In fact as briefly mentioned earlier, there is a layer of security in a setup like this, and it’s typically good practice not to leave anything open to the WAN that doesn’t have to be. So with this said, it’s not abnormal for restrictive default configurations to be found in routing equipment. If you don’t have access to the administration panel to configure ports to do things liketrigger, open, and forward, you may find yourself at a standstill serving anything yourself to anyone beyond your LAN.

Reverse tunneling SSHis a solution to the aforementioned problem above. This is admittedly a vague scenario outlined above, so here are a couple ofreal worldexamples:

1 - To create a public access point
shadow[dot]techrents virtual computer systems which accessible using their proprietary software which acts similar in function toRemote Desktop Protocol. Transferring files from your computer to the shadow computer can be done using their software, dragging and dropping a file from your computer onto the shadow computer desktop, however this presents as slow and will often error out or drop before the file is finished transferring with no method of continuing a dropped download that has failed. The Shadow system does not have an public IP address, so enabling the SSH server and attempting to connect and transfer files via SCP or similar fails.
A reverse SSH tunnel resolves the missing public IP address issueand even increases the speed at which data can transfer between you and the shadow pc. This opens up a multitude of methods to transfer the files,many of which may include resuming a transfer if a connection is dropped- a massive benefit when transferring large files.

2 - To forward a service to the public
You’ve been playing around with ComfyUI, the Stable Diffusion webUI and you want to share it with some close friends. Unfortunately, ComfyUI doesn’t come with the**–share**option which is built into ATOMIC1111111’s UI using thegradio API. But even if it was, you anticipate issues with certificates, the 72 hour link expiry using gradio, and prefer to self host it yourself. At the moment, you and everyone on your network can access the webui at the url “http://192.168.1.55:8188“. But when you try to share it with some family that live on the other side of the country, they get error messages/
By creating a reverse tunnel from a publicly accessible server to your service, you have now opened a door for the world wide web to access it. This is not limited to HTTP as a service by any stretch. For instance,SFTPis merely the FTP service combined with an SSH tunnel.

3 - To add an extra layer of security
This goes for tunneling SSH in general. You are concerned with the idea of your ISP watching you download music off torrents or some seedy websites you’ve come across. The data running through the tunnel is encrypted from one end to the other. So by creating a tunnel on a publicly available server, then downloading through that tunnel, you’ve added an additional layer of privacy from prying eyes.

The image above is an attempt to help visualize an example of the most basic reverse tunnel. John has a home network but wants to be able to access some of the files on his computer,Device 1, when he’s away from home. He has a shell account on his favorite websites server,dtrh.net, which is accessible through his account**“john”via SSH onport 7822**. To help break it down, this is the basic command John would use to login to his SSH account:sshjohn@dtrh.net-p7822

At home, John has the SSH daemon running onport 22, which is the default port used for SSH. He wants to use dtrh.net to bounce his connection back home. To do this, a connection between his home computer and dtrh.net must be established ahead of time. He will forward any connections made onport 2900atdtrh.netback home toport 22where his SSH service is running:-R 2900:localhost:22

Reverse SSH Tunnel:A bidirectional tunnel from remote device to local device over SSHCommand:ssh -R [remote_src_port]:[local_host]:[local_dest_port] [remote_user]@[remote_host] -p [remote_daemon_port]-RReverse tunnel flag, remember this is case sensitiveremote_src_portThis is the port on the remote machine that will route data through the tunnel to your local device.local_hostThis is your local device running the service you want to make accessible beyond it’s LAN. You can typically use any local reference, includinglocalhost,127.0.0.1,192.168.x.x,10.0.0.x, etc.local_dest_portThis is the port on your local device you are running a service on that you wish to make public. This is the port you want incomming connections made topublic_fwd_portto be tunnelled to.remote_userThis is the user account on the publicly accessible remote machine which had shell and SSH access.remote_hostThis is the publicly accessible remote machine host name or IP address which will be forwarding connections to your port/serviceremote_daemon_portThis is the publicly accessible remote machines port running the SSH daemon. In other words, for any other normal SSH session, this is the port you would use

If it makes it easier,remoteandpublicare interchangeable here, and are referring to the system which does not have a restrictive firewall infront of it; it has a public IP address.

PUTTING IT TOGETHER

There are still a few important bits of the puzzle left to discuss. As mentioned earlier, tunneling data through SSH adds a layer of security. How? in creating a tunnel, and as can be seen in the command example above, you are authenticating with the remote server under a user account. This could be a password, keyfile, or any other relevant setup. As long as that initial connection authenticates without issue and is intact, the tunnel remains (though, you may need to use a tool likeautosshand set TTL parameters in reality for long lasting tunnels). I’ve attached a real world example illustrating the process using two of my servers and my home network:

The image shows I’m connected to a VPN at home, under the user KBS. I create a remote tunnel from my VPS rabbit-hole.ca backwards to my computer, where any data sent to port 2900 on rabbit-hole.ca will return back to my computer on port 22. After running the command, I am asked to autenticate the user accountdtrh@rabbit-hole.ca, and after authenticating I am given a shell on rabbit-hole.ca.When this session terminates, so does every other connection running through it. Utilizing the SSH flags**-fN**, you can dump the terminal session to the foreground and disable input as a means of easily identifying the terminal running with the active tunnel.

Take a look at the screen on the right. I log into my seedbox, located in the states, and attempt to connect via SSH to my public IP as shown by my VPN. It’s no surprise this does not work.By connecting to my local user account (kbs) at the public server and forwarded port, I can now connect back home to resources such as ssh in this example.. I’m left with a shell, accessible by means of the tunnel from rabbit-hole.ca to home.

SOME FUN EXAMPLES

You can test outStable Diffusion AI Image Generation using ATOMIC111111’s WebUI here if my shadow PC is on
You can test out the true power ofStable Diffusion AI Image Generation using ComfyUI Workflows if my shadow PC is on

I am serving both of these via HTTP service through an SSH reverse tunnel on a system with no public IP via forwarding with my VPS.

A WORD OF CAUTION

The beginning of this text loosely outlines the idea that having a restrictive firewall/gateway is beneficial from a security standpoint. These tunnels allow you to do some cool stuff, but they can just as easily open holes up exposing potentially unwanted and sensitive data to the world. Take care in properly closing any tunnels you are no longer using. A good rule of thumb is if you can avoid opening public ports and get the results you are after, leave them closed. Anything open to the public should be considered a potential security risk.

THERES MORE?

This text is far from complete - there is much more to these topics than I’ve covered here, and they could be covered in much more detail. With that said, I feel as though this could act as an informative post for anyone getting their feet wet with these types of operations.