Hello! Are you fascinated by the world of remote access using SSH? In previous posts, I covered SSH key generation, basic commands, and local port forwarding using the -L option. This time, we will focus on another powerful feature of SSH known as Reverse Port Forwarding, specifically the -R option.

If the -L option is about "tunneling from my computer to access external resources," the -R option is the opposite: it allows "tunneling from an external computer to access internal resources," similar to creating a door in a wall.

What is Reverse Port Forwarding? (Overview of the -R option)

Generally, accessing a local computer (Client B) directly from a remote server (Server A) can be challenging. This is often because Client B uses a private IP address, is behind a firewall, or lacks a static IP.

In such cases, by using reverse port forwarding (-R option), Client B can attempt to SSH connect to Server A while simultaneously creating a tunnel in Server A to forward requests coming into a specific port on Server A to a specific port on Client B.

In simple terms:

  1. Client B (my computer) attempts SSH connection to Server A (external server).
  2. At this time, it uses the -R option to command, "Forward requests coming into port X of Server A to port Y of my computer (Client B)!".
  3. Now, when another external user connects to port X of Server A, that request is forwarded through the SSH tunnel to port Y of Client B.

This is like Client B asking Server A to "create a door for me to connect to".

SSH Reverse Port Forwarding flowchart: structure connecting external requests through the server to local

Structure of the -R Command

The basic command format for reverse port forwarding is as follows.

ssh -R [remote_port]:[target_host]:[target_port] [remote_server_user]@[remote_server_address]

Let's break down each component:

  • ssh: Command to run the SSH client.
  • -R: Option for reverse port forwarding.
  • [remote_port]: The port number on the remote server (Server A) to create a tunnel. When an external user connects to this port, they will connect to resources on Client B.
  • [target_host]: The hostname or IP address of the resource accessible within Client B (my computer) when [remote_server_user]@[remote_server_address] connects. This is usually localhost (i.e., Client B itself).
  • [target_port]: The port number of the service running on Client B (my computer). This is where incoming requests will ultimately arrive.
  • [remote_server_user]@[remote_server_address]: The user account and address of the external server (Server A) to establish the tunnel. This is the path for Client B to connect to Server A.

Example:

When you want to access the web server running on port 8080 of your local computer (Client B) through port 8888 of the external server (Server A):

# Run on Client B (my computer)
ssh -R 8888:localhost:8080 user@server_a_public_ip

If this command executes successfully, you will be connected via SSH to server_a_public_ip. Now, if another computer connects to http://server_a_public_ip:8888, it will actually access port 8080 of Client B (my computer).

When is Reverse Port Forwarding Useful? (Use Cases in Development)

Reverse port forwarding is incredibly powerful in specific scenarios where standard SSH connections fall short. This is particularly useful in development contexts.

1. Exposing Local Development Server Behind NAT/Firewall

  • Problem: You have a web application you are developing within a home or company network (for example, running on localhost:3000). You want to show this application to external team members or clients, but your local computer uses a private IP and can't be accessed directly from outside. Router or corporate firewall settings can be complex and may require admin approval.
  • Solution: You can expose your local development server to the outside using an external server (e.g., AWS EC2 instance, VPS) with a public IP.
# Run on my local development machine (Client B)
ssh -R 80:localhost:3000 your_user@your_public_server.com
# Or since port 80 requires root permissions, use another port (e.g., 8080)
ssh -R 8080:localhost:3000 your_user@your_public_server.com

Now, by connecting to `your_public_server.com:8080`, you will actually access the web application running on your local machine (`localhost:3000`). You can now show your development progress in real time to external users.

2. Testing Webhooks

  • Problem: You want to test webhook events occurring from payment systems, Git repositories (GitHub/GitLab), messaging platforms, etc., on your local development server. However, webhooks can only be sent to Public URLs.
  • Solution: You can map a local webhook endpoint (for example, localhost:5000/webhook) to a specific URL on a public server using reverse port forwarding.
# Run on my local development machine (Client B)
ssh -R 5000:localhost:5000 your_user@your_public_server.com

Now, when you enter `http://your_public_server.com:5000/webhook` in the webhook settings, the webhook events will be delivered to your local server for testing.

3. Direct Access to Specific Port on Remote Server (Bypassing Secure Network)

  • Problem: You want to directly access a database or internal management tool (for example, running on localhost:9000) installed on a remote server (Client B), but that server's specific ports are blocked by a firewall or is behind a private network. However, Client B can SSH connect to an external public server (Server A).
  • Solution: Client B SSH connects to Server A while requesting to set up reverse port forwarding, saying, "Please create a pathway connecting to my port 9000".
# Run on Client B (server behind firewall)
ssh -R 9000:localhost:9000 your_user@server_a_public_ip

Now, when you connect to `server_a_public_ip:9000` from your computer (or other external computers), you can access the services on port 9000 of Client B.

4. Temporary Demos or Sharing

  • Problem: You want to show a colleague how a specific application running on your local machine works, or you want to temporarily expose it to receive feedback.
  • Solution: Simple reverse port forwarding can expose a specific local service to the outside for a limited time. Once the demo ends, you can terminate the SSH session to block access, which is very convenient.

Precautions When Using Reverse Port Forwarding

  • GatewayPorts yes: The remote ports opened by reverse port forwarding are accessible only from the machine on which the SSH server (server_a_public_ip) is running by default. If you want other external computers to access this port, you need to add the GatewayPorts yes setting to the SSH server's sshd_config file and restart the SSH service. (Be cautious with this setting as it may affect security.)

  • Security: Since reverse port forwarding exposes a specific port of your local network to the outside, it should only be used with trusted servers. You should thoroughly check for security vulnerabilities in the exposed service.

  • Maintaining SSH Session: The reverse port forwarding tunnel is only valid while the SSH session is active. To run it in the background continuously, it is common to use ssh -fN -R ... with the f (run in background) and N (do not execute remote commands) options together.

In Conclusion

SSH reverse port forwarding (-R option) is an immensely useful feature when needing to expose specific services from behind complex network environments or firewalls. It can serve as a powerful productivity tool, especially when sharing local development environments or testing webhooks.

If this concept was hard to grasp, the best way to understand it is to try it out in practice. Actively utilize SSH reverse port forwarding in your development workflow!

If you have any questions, feel free to ask in the comments!