> ## Content Index > Fetch the complete content index at: https://snubmonkey.com/llms.txt > Use this file to discover other available public pages before exploring further. # SSH Port Forwarding β€³ aka SSH Tunneling β€” Remote Port Forwarding (Part 2) - URL: https://snubmonkey.com/ssh-port-forwarding-aka-ssh-tunneling-remote-port-forwarding-part-2/ - Published: 2026-09-09T00:04:39.000Z - Updated: 2026-09-09T00:04:40.000Z - Description: Learn how SSH remote port forwarding securely makes local services accessible from remote systems. Explore ssh -R, reverse SSH tunnels, NAT and firewall traversal, GatewayPorts, security considerations, and practical examples. - Author: SNUBmonkeyteam - Tags: how to πŸͺ„, ethical hacking πŸ€–, SSH πŸ•³, security 🦾🦿 # SSH Tunneling β€” Part 2: Remote Port Forwarding *How reverse SSH tunnels make local services accessible from remote systems* In [Part 1](https://snubmonkey.com/ssh-port-forwarding-aka-ssh-tunneling-local-port-forwarding-part-1/), we used **local port forwarding (`-L`)** to access a remote service from our local machine. This time, we **reverse** the direction. **Remote port forwarding (`-R`)** allows a service running on your local machineβ€”or on a host reachable from itβ€”to be accessed through a listening port on the remote SSH server. This is commonly called a **reverse SSH tunnel**. ## How SSH Port Forwarding Works SSH supports three primary forwarding modes: 1. **Local port forwarding (`-L`)** β€” a local port forwards to a service reachable from the remote side. 2. **Remote port forwarding (`-R`)** β€” a remote port forwards to a service reachable from the local side. 3. **Dynamic port forwarding (`-D`)** β€” creates a SOCKS proxy that dynamically forwards connections through the SSH server. The key difference between `-L` and `-R` is **where the listening port is created**. ### Local forwarding ``` Local Machine localhost:8080 β”‚ β”‚ SSH tunnel β–Ό Remote Server localhost:3000 ``` ### Remote forwarding ``` Remote Server localhost:8080 β”‚ β”‚ SSH tunnel β–Ό Local Machine localhost:3000 ``` With `-R`, the SSH connection is still established from the local machine to the remote server. What changes is **where SSH creates the listening port**. # Remote Port Forwarding (`-R`) Remote port forwarding allows you to expose a service reachable from your local machine through a port on the remote SSH server. The basic syntax is: ``` $ ssh -N -R [REMOTE_BIND_ADDRESS:]REMOTE_PORT:DESTINATION_HOST:DESTINATION_PORT user@REMOTE_SERVER ``` The easiest way to think about it is: ``` -R REMOTE_PORT:DESTINATION_HOST:DESTINATION_PORT ``` > Create a listening port on the remote side and send its traffic through SSH to the destination on the local side. ## A Practical Example Suppose you have a web application running on your local machine: ``` localhost:2399 ``` You want a remote server to be able to access that application. Create the reverse tunnel: ``` $ ssh -N -R 2393:localhost:2399 user@REMOTE_SERVER_IP ``` SSH establishes the connection from your machine to: ``` REMOTE_SERVER_IP ``` and creates a listening port: ``` REMOTE_SERVER_IP:2393 ``` The traffic flow becomes: ``` Remote Server localhost:2393 β”‚ β”‚ SSH tunnel β–Ό Your Local Machine localhost:2399 β”‚ β–Ό Web Application ``` Now, a process running on the remote server can connect to: ``` localhost:2393 ``` and its traffic is carried through the existing SSH connection to: ``` localhost:2399 ``` on your local machine. ### The important distinction The SSH connection itself is: ``` Your Machine ───────────► Remote Server ``` But the forwarded traffic flows: ``` Remote Server ──────────► Your Machine ``` That is why this is commonly called a **reverse tunnel**. The SSH session does not reverse direction. **The forwarded connection does.** # Why Reverse SSH Tunneling Is Useful Remote port forwarding is particularly useful when the machine running the service cannot accept inbound connections. For example: ``` Your Laptop β”‚ β”‚ outbound SSH connection β–Ό Remote Server ``` Your laptop might be behind: - NAT - A home router - A corporate firewall - CGNAT - A restrictive network Normally, the remote server cannot establish a direct connection back to your laptop. But if your laptop can establish an **outbound SSH connection**, it can create a reverse tunnel: ``` Your Laptop β”‚ β”‚ SSH connection β–Ό Remote Server β”‚ β”‚ remote forwarded port β–Ό └──────────► SSH tunnel ──────────► Your Laptop ``` No inbound connection to your laptop is required. This makes reverse tunneling useful for remote development, testing, temporary access, and reaching services behind restrictive network boundaries. # The Destination Does Not Have to Be `localhost` Just like local forwarding, the destination does not have to be `localhost`. For example: ``` $ ssh -N -R 8080:10.10.20.50:80 user@REMOTE_SERVER ``` The remote server listens on port `8080`, while traffic is forwarded through the SSH connection to: ``` 10.10.20.50:80 ``` from the local side's network perspective. This can be useful when your local machine can reach an internal service that the remote server cannot reach directly. For example: ``` Remote Server β”‚ β”‚ connects to :8080 β–Ό Remote SSH Forward β”‚ β”‚ SSH tunnel β–Ό Your Local Network β”‚ β–Ό 10.10.20.50:80 ``` The SSH client acts as the bridge between the two network contexts. # Controlling Who Can Access the Remote Port There is an important security detail with `-R`. By default, OpenSSH binds remote forwarded ports to the loopback interface. In practice, this usually means the forwarded port can only be accessed from the remote server itself. For example: ``` $ ssh -N -R 8080:localhost:2399 user@REMOTE_SERVER ``` typically creates: ``` Remote Server 127.0.0.1:8080 ``` rather than: ``` Remote Server 0.0.0.0:8080 ``` This default is important because it prevents a reverse tunnel from automatically becoming a publicly accessible service. # GatewayPorts The SSH server's `GatewayPorts` setting controls whether remote forwarded ports can be accessed from other hosts. It is configured in: ``` /etc/ssh/sshd_config ``` The main options are: ### `GatewayPorts no` This is the default. Remote forwarding is bound to the loopback interface, so the forwarded port is normally accessible only from the SSH server itself. ``` 127.0.0.1:8080 ``` ### `GatewayPorts yes` Allows remote forwarded ports to bind to wildcard addresses. For example: ``` 0.0.0.0:8080 ``` If the server is publicly reachable, this can make the forwarded service accessible from the Internet. This should therefore be enabled only when there is a clear requirement and appropriate network controls are in place. ### `GatewayPorts clientspecified` Allows the SSH client to specify the address on which the remote forwarded port should listen. For example: ``` $ ssh -N -R 15.152.66.244:8080:localhost:80 user@REMOTE_SERVER ``` This requests that the remote forwarding listen specifically on: ``` 15.152.66.244:8080 ``` rather than all interfaces. Whether this works depends on the SSH server configuration and the address being available on the remote host. # Remote Forwarding and Security A reverse tunnel can be extremely usefulβ€”but it can also unintentionally turn a private service into a remotely accessible one. For example: ``` Private Service localhost:2399 β”‚ β”‚ SSH tunnel β–Ό Public Server :8080 β”‚ β–Ό Potential external access ``` If the remote forwarded port is bound to a public interface, anyone who can reach that port may potentially reach the service behind the tunnel. For this reason: - Keep remote forwards bound to loopback unless external access is required. - Restrict which users are allowed to create forwarding tunnels. - Use firewall rules to limit access where appropriate. - Monitor persistent SSH connections. - Avoid exposing administrative interfaces or sensitive services unnecessarily. - Use SSH authentication controls and least privilege. A reverse tunnel should be treated as a **network access mechanism**, not simply as a convenient port mapping. # Running a Reverse Tunnel in the Background For a tunnel that does not require an interactive shell: ``` $ ssh -f -N \ -R 127.0.0.1:2393:localhost:2399 \ user@REMOTE_SERVER ``` The remote server now has: ``` 127.0.0.1:2393 ``` forwarding to: ``` Your Machine β†’ localhost:2399 ``` You can verify the listening port on the remote server with: ``` $ ss -lntp ``` # Keeping a Reverse Tunnel Alive For long-running reverse tunnels, SSH keepalives can help detect broken connections: ``` $ ssh -N \ -o ServerAliveInterval=30 \ -o ServerAliveCountMax=3 \ -R 127.0.0.1:2393:localhost:2399 \ user@REMOTE_SERVER ``` For persistent environments, `autossh` can automatically restart a failed SSH connection: ``` $ autossh -M 0 -N \ -o ServerAliveInterval=30 \ -o ServerAliveCountMax=3 \ -R 127.0.0.1:2393:localhost:2399 \ user@REMOTE_SERVER ``` Keepalives help detect a dead connection; `autossh` adds automatic recovery when the SSH session terminates. # Troubleshooting If the reverse tunnel does not work, start with verbose SSH output: ``` $ ssh -vvv -N \ -R 127.0.0.1:2393:localhost:2399 \ user@REMOTE_SERVER ``` Then verify the remote listening socket: ``` $ ss -lntp ``` On the remote server, test the forwarded port: ``` $ curl http://127.0.0.1:2393 ``` If the remote port is listening but the connection fails, verify that the destination service is reachable from the machine running the SSH client: ``` $ curl http://127.0.0.1:2399 ``` The diagnostic path is therefore: ``` Remote listener works? β”‚ β–Ό SSH connection works? β”‚ β–Ό Local destination reachable? β”‚ β–Ό Application responding? ``` This helps isolate whether the problem is with SSH, forwarding, networking, or the application itself. # Quick Reference ### Basic reverse tunnel ``` $ ssh -N -R 8080:localhost:3000 user@server ``` ``` Remote :8080 β†’ Local :3000 ``` ### Explicit loopback binding ``` $ ssh -N -R 127.0.0.1:8080:localhost:3000 user@server ``` ### Forward to another local-network host ``` $ ssh -N -R 8080:10.10.20.50:80 user@server ``` ### Background tunnel ``` $ ssh -f -N -R 127.0.0.1:8080:localhost:3000 user@server ``` ### Debugging ``` $ ssh -vvv -N -R 127.0.0.1:8080:localhost:3000 user@server ``` # The Mental Model If `-L` means: ``` -L Local listener β”‚ β–Ό Remote destination ``` then `-R` means: ``` -R Remote listener β”‚ β–Ό Local destination ``` A simple way to remember it: ``` -L β†’ Listen here, reach there. -R β†’ Listen there, reach here. ``` The SSH connection itself still originates from the local machine: ``` Local ───────────► SSH Server ``` But with remote forwarding, connections arriving at the remote listener are carried back through that SSH session: ``` Remote listener β”‚ β–Ό SSH tunnel β”‚ β–Ό Local destination ``` Once this distinction is clear, `-R` becomes much easier to reason about. ## What’s Next? Remote forwarding moves traffic **from a remote system toward a service on your local side**. In this tutorial, we used **remote port forwarding (`-R`)** to make a local service accessible through a remote SSH serverβ€”without requiring a direct inbound connection to the local machine. The key idea is simple: ``` -R REMOTE_PORT:DESTINATION_HOST:DESTINATION_PORT ``` **Create the listener on the remote side, and carry the traffic back through the existing SSH connection to the destination on the local side.** In the next part, we move beyond fixed port mappings with **dynamic port forwarding (`-D`) and SOCKS proxies**, allowing applications to dynamically route TCP connections through an SSH server. As we wrap up this tutorial, I’d like to sincerely thank everyone who took part and contributed along the way. Your questions, ideas, and curiosity are what make learning truly valuable. Learning is a collaborative journey, so keep exploring, keep asking questions, and don’t be afraid to dig deeper. Thank you again for being part of it, and best of luck on the journey ahead!