Skip to content
ZestSSH Docs

Remote Forwards

Remote forwarding opens a listening port on the SSH server that tunnels connections back to a host and port on your local device. Traffic flows in the opposite direction from local forwarding: from the server side, through the SSH tunnel, to your device.

Equivalent SSH command: ssh -R [remote_address:]remote_port:local_host:local_port user@server

When you actually want this

Section titled “When you actually want this”

Remote forwarding is uncommon. Most people never need it. But it solves a specific class of problems where something on the server side needs to reach something on your side:

  • Showing a local dev server to a colleague. You are developing a web app on your laptop. A teammate who has SSH access to a shared server needs to see it. You set up a remote forward so that the server’s port 9090 tunnels back to your laptop’s port 3000.
  • Webhook testing. A server-side application needs to send HTTP callbacks to a service running on your machine. Rather than deploying the service, you tunnel the webhook traffic back through SSH.
  • Reverse shell for debugging. A process on the server needs to connect to a debugger or logging agent running on your device.
  • Exposing a local database for a server-side migration script. A migration tool on the server needs to read from a database on your laptop. You forward the server’s port 3306 back to your local MySQL instance.

If your use case does not match one of these patterns — if you are trying to reach something on the server from your device — you want Local Forwarding instead.

Server configuration: GatewayPorts

Section titled “Server configuration: GatewayPorts”

By default, most SSH servers bind remote forwarded ports to 127.0.0.1 on the server side, meaning only processes on the server itself can connect. If you need other machines on the server’s network to reach the forwarded port, the server administrator must edit /etc/ssh/sshd_config:

GatewayPorts yes

Or, for more control:

GatewayPorts clientspecified

The clientspecified option lets the SSH client choose the bind address (e.g., 0.0.0.0 for all interfaces). After changing the config, restart the SSH daemon (sudo systemctl restart sshd).

Without GatewayPorts, the remote forward is private to the server — which is actually the safest default and is sufficient when only server-side processes need the tunnel.

Configuring in ZestSSH

Section titled “Configuring in ZestSSH”
  1. Connect to your server and open the port forwarding screen.
  2. Tap Add Forward.
  3. Select the Remote type using the segmented control.
  4. Fill in the fields:
    • Nickname: Something descriptive, like “Dev server reverse tunnel.”
    • Source Port: The port that will open on the server. (Yes, for remote forwards the “source” is the remote side.)
    • Destination Host: Where the tunnel exits on your side. Usually localhost (your device).
    • Destination Port: The port of the service on your device.
    • Bind Address: Leave as 127.0.0.1 unless you need the server to listen on all interfaces.
  5. Tap Add and start the forward.

Reading the description: ZestSSH displays remote forwards with the arrow reversed compared to local forwards. A remote forward shows as remoteHost:remotePort --> bindAddress:bindPort, making it visually clear that traffic flows from the server to your device.

Example: sharing a local web app

Section titled “Example: sharing a local web app”

You have a React development server running on your laptop at localhost:3000. Your colleague can SSH into shared-server.example.com and you want them to see your app at http://localhost:9000 on that server.

In ZestSSH:

Type:              Remote
Source Port:       9000
Destination Host:  localhost
Destination Port:  3000

Your colleague SSHs into the shared server and opens http://localhost:9000 in a terminal browser or forwards that port to their own machine. The request travels through your SSH tunnel back to your laptop’s port 3000.

Example: webhook testing

Section titled “Example: webhook testing”

A CI/CD pipeline on the server sends a POST to http://localhost:8888/webhook when a build completes. You want that webhook to reach a handler running on your laptop at port 8888.

Type:              Remote
Source Port:       8888
Destination Host:  localhost
Destination Port:  8888

The server-side pipeline hits localhost:8888, the request tunnels through SSH to your laptop, and your handler processes it.

Security considerations

Section titled “Security considerations”
  • Remote forwards effectively punch a hole from the server into your local network. Only forward to services you intend to expose.
  • Binding to 127.0.0.1 on the server side restricts access to processes running on the server itself. This is the safest option.
  • If GatewayPorts is enabled and the forward binds to 0.0.0.0, anyone who can reach the server can connect through the tunnel to your device. Use this with caution.
  • Remote forwards close when the SSH session ends. There is no persistent exposure after disconnecting.

Troubleshooting

Section titled “Troubleshooting”

“Address already in use”: Another process on the server is already listening on the port you chose. Pick a different source port.

Connection refused after setup: Check that the service on your local device is actually running and listening on the destination port. Also verify that you selected the Remote type and not Local.

Remote clients cannot connect: The server’s GatewayPorts is likely set to no (the default). Ask the server administrator to change it, or have the remote client connect to the server’s localhost instead.

Section titled “Related”