How to access a Linux server behind NAT via reverse SSH tunnel

You are running a Linux server at home, which is behind a NAT router or restrictive firewall. Now you want to SSH to the home server while you are away from home. How would you set that up? SSH port forwarding will certainly be an option. However, port forwarding can become tricky if you are dealing with multiple nested NAT environment. Besides, it can be interfered with under various ISP-specific conditions, such as restrictive ISP firewalls which block forwarded ports, or carrier-grade NAT which shares IPv4 addresses among users.

What is Reverse SSH Tunneling?

One alternative to SSH port forwarding is reverse SSH tunneling. The concept of reverse SSH tunneling is simple. For this, you will need another host (so-called "relay host") outside your restrictive home network, which you can connect to via SSH from where you are. You could set up a relay host using a VPS instance with a public IP address. What you do then is to set up a persistent SSH tunnel from the server in your home network to the public relay host. With that, you can connect "back" to the home server from the relay host (which is why it's called a "reverse" tunnel). As long as the relay host is reachable to you, you can connect to your home server wherever you are, or however restrictive your NAT or firewall is in your home network.

Set up a Reverse SSH Tunnel on Linux

Let's see how we can create and use a reverse SSH tunnel. We assume the following. We will be setting up a reverse SSH tunnel from homeserver to relayserver, so that we can SSH to homeserver via relayserver from another computer called clientcomputer. The public IP address of relayserver is

On homeserver, open an SSH connection to relayserver as follows.

homeserver~$ ssh -fN -R 10022:localhost:22 relayserver_user@

Here the port 10022 is any arbitrary port number you can choose. Just make sure that this port is not used by other programs on relayserver.

The "-R 10022:localhost:22" option defines a reverse tunnel. It forwards traffic on port 10022 of relayserver to port 22 of homeserver.

With "-fN" option, SSH will go right into the background once you successfully authenticate with an SSH server. This option is useful when you do not want to execute any command on a remote SSH server, and just want to forward ports, like in our case.

After running the above command, you will be right back to the command prompt of homeserver.

Log in to relayserver, and verify that is bound to sshd. If so, that means a reverse tunnel is set up correctly.

relayserver~$ sudo netstat -nap | grep 10022
tcp      0    0*               LISTEN      8493/sshd           

Now from any other computer (e.g., clientcomputer), log in to relayserver. Then access homeserver as follows.

relayserver~$ ssh -p 10022 homeserver_user@localhost

One thing to take note is that the SSH login/password you type for localhost should be for homeserver, not for relayserver, since you are logging in to homeserver via the tunnel's local endpoint. So do not type login/password for relayserver. After successful login, you will be on homeserver.

Connect Directly to a NATed Server via a Reverse SSH Tunnel

While the above method allows you to reach homeserver behind NAT, you need to log in twice: first to relayserver, and then to homeserver. This is because the end point of an SSH tunnel on relayserver is binding to loopback address (

But in fact, there is a way to reach NATed homeserver directly with a single login to relayserver. For this, you will need to let sshd on relayserver forward a port not only from loopback address, but also from an external host. This is achieved by specifying GatewayPorts option in sshd running on relayserver.

Open /etc/ssh/sshd_conf of relayserver and add the following line.

relayserver~$ vi /etc/ssh/sshd_conf
GatewayPorts clientspecified

Restart sshd.

Debian-based system:

relayserver~$ sudo /etc/init.d/ssh restart

Red Hat-based system:

relayserver~$ sudo systemctl restart sshd

Now let's initiate a reverse SSH tunnel from homeserver as follows.

homeserver~$ ssh -fN -R relayserver_user@

Log in to relayserver and confirm with netstat command that a reverse SSH tunnel is established successfully.

relayserver~$ sudo netstat -nap | grep 10022
tcp      0      0*           LISTEN      1538/sshd: dev  

Unlike a previous case, the end point of a tunnel is now at (relayserver's public IP address), not This means that the end point of the tunnel is reachable from an external host.

Now from any other computer (e.g., clientcomputer), type the following command to gain access to NATed homeserver.

clientcomputer~$ ssh -p 10022 homeserver_user@

In the above command, while is the public IP address of relayserver, homeserver_user must be the user account associated with homeserver. This is because the real host you are logging in to is homeserver, not relayserver. The latter simply relays your SSH traffic to homeserver.

Set up a Persistent Reverse SSH Tunnel on Linux

Now that you understand how to create a reverse SSH tunnel, let's make the tunnel "persistent", so that the tunnel is up and running all the time (regardless of temporary network congestion, SSH timeout, relay host rebooting, etc.). After all, if the tunnel is not always up, you won't be able to connect to your home server reliably.

For a persistent tunnel, I am going to use a tool called autossh. As the name implies, this program allows you to automatically restart an SSH session should it breaks for any reason. So it is useful to keep a reverse SSH tunnel active.

As the first step, let's set up passwordless SSH login from homeserver to relayserver. That way, autossh can restart a broken reverse SSH tunnel without user's involvement.

Next, install autossh on homeserver where a tunnel is initiated.

From homeserver, run autossh with the following arguments to create a persistent SSH tunnel destined to relayserver.

homeserver~$ autossh -M 10900 -fN -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R relayserver_user@

The "-M 10900" option specifies a monitoring port on relayserver which will be used to exchange test data to monitor an SSH session. This port should not be used by any program on relayserver.

The "-fN" option is passed to ssh command, which will let the SSH tunnel run in the background.

The "-o XXXX" options tell ssh to:

  • Use key authentication, not password authentication.
  • Automatically accept (unknown) SSH host keys.
  • Exchange keep-alive messages every 60 seconds.
  • Send up to 3 keep-alive messages without receiving any response back.

The rest of reverse SSH tunneling related options remain the same as before.

If you want an SSH tunnel to be automatically up upon boot, you can add the above autossh command in /etc/rc.local.


In this post, I talked about how you can use a reverse SSH tunnel to access a Linux server behind a restrictive firewall or NAT gateway from outside world. While I demonstrated its use case for a home network via a public VPS, you must be careful when applying it for corporate networks. Such a tunnel can be considered as a breach of a corporate policy, as it circumvents corporate firewalls and can expose corporate networks to outside attacks. There is a great chance it can be misused or abused. So always remember its implication before setting it up.

Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

Support Xmodulo

Did you find this tutorial helpful? Then please be generous and support Xmodulo!

The following two tabs change content below.
Dan Nanni is the founder and also a regular contributor of He is a Linux/FOSS enthusiast who loves to get his hands dirty with his Linux box. He likes to procrastinate when he is supposed to be busy and productive. When he is otherwise free, he likes to watch movies and shop for the coolest gadgets.

12 thoughts on “How to access a Linux server behind NAT via reverse SSH tunnel

  1. When I need to solve this problem (restricted NAT), I will use this:

    - on the vps, I install openvpn with certificates in UDP mode
    - on the remote host and on the internal sever I install openvpn-client (auth with client certificate and password)
    - so in the end, you can initiate any ssh connection from remote-host to the internal server (using the IP address of the openvpn tunnel)

    - you have two auth factor (password and certificate) when you want to start openvpn client
    - open-vpn will be a second layer for the ssh communication
    - open-vpn in udp mode is more stealthy compared with ssh on tcp
    - and if you set up the openvpn in bridge mode, you can even use a dedicate VLAN for open-vpn

    • Thanks for your comment. VPN can be another option. But I would prefer SSH for ease of setup.

      > open-vpn in udp mode is more stealthy compared with ssh on tcp

      I thought the opposite. If a firewall is set to block unrecognized encrypted application protocols, it will block OpenVPN. But SSH is whitelisted in many corporate networks.

      • I was telling about the ssh installed on the vps, not related with the any corporate networks. For example if you scan the vps, it is easy to discover ssh daemon, but to discover open-vpn (running on a udp port), you need a lot of time.
        On a corporate network, any ssh traffic is treated with a lot of care/attention, so it is hard to cover any ssh link. But if you want very hard to escape, you could use openvpn (server side) in TCP mode, running on tcp/443 (with ssl encryption). In this case any link to a VPS will be like as any other browsing activity. You could even use openvpn with any http/https proxy like any other http/https client.

        And you are right. ssh is easy, but think for a moment there was time in the past when all of us discovered a bug in ssl (Heartbleed). At that time any admin who used ssh could not sleep very well, until the patch was available! I was running ssh with Heartbleed bug for many years!

        But for some others admins (me included), open-vpn (udp/tls-auth, and ssh accessible only from the open-vpn tunnel) was very happy, because it was not vulnerable (TLS-auth on top of the SSL - see

        In conclusion, some setups are easy to made, others are more complicated, each of them has advantages and disadvantages at the same time.

  2. No need for autossh. There's a simpler way to get the ssh tunnel persistent though - just throw the initiating ssh process under init control (put a dedicated 'respawn' record in /etc/inittab). The only thing to keep in mind then is to avoid too frequent respawns, which can be done by controlling reception of 'icmp host-unreachable', that essentially controls when the initiating ssh gives up another tunnel init attempt...

  3. Nice and clean article thank you. That could be useful to manage home raspberry without messing the home router.

    Can the same trick be used to expose other services? Like a MySQL database for example?

    • Sure certainly it can. Simply replace SSH port with MySQL port (3306). Something like will do:

      homeserver~$ ssh -fN -R 10022:localhost:3306 relayserver_user@
      relayserver~$ mysql -h -P 10022 -u user -p db

  4. Excellent.

    I've been searching for something close like that so I can access services that come out of my home network, which is NATed.

    At least for SSH now I know how to do it.
    I'd like to know if it's possible for an arbitrary service on another port (like VPN port) and how can I do it.

    I don't master very well using VPNs and stuff...(I've read the above comments too)

    Thanks for the article.

  5. Hi, thank you a lot for these explanations.
    I would like to make sure about one thing. If I have multiple homeservers at different places but all are behind NAT. Can we access them all from one single vps? Is it sufficient to create each ssh connection to a specific port on the relay server (10022 for homeserver 1, 10023 for homeserver 2, etc)
    Thank you for your response.
    Weber Jerem

Leave a comment

Your email address will not be published. Required fields are marked *