A reverse SSH tunnel opens a port on a remote SSH server and forwards traffic back to a service reachable from your local machine. Developers use it when their local machine sits behind NAT or a firewall but the remote server has a public address.
This is the DIY path for exposing localhost through infrastructure you control. It works, but it puts server setup, access control, expiry, and logging on you.
Reverse SSH tunnel command pattern
The core flag is -R:
ssh -N -R 8080:127.0.0.1:3000 user@vps.example.com
Read it from the remote server’s point of view:
- Listen on port
8080onvps.example.com. - When a connection arrives, send it through the SSH session.
- Connect from the local machine to
127.0.0.1:3000.
The -N flag tells SSH not to run a remote shell command. You only want the tunnel.
In many default SSH server configs, the remote listener binds to loopback on the server. That means only the server itself can reach it. To make the port public, you may need GatewayPorts in sshd_config, plus a firewall rule and a process reload.
Example server config:
GatewayPorts clientspecified
Then run a bind-address form. Only use this form when you intend to expose the port, since a public reverse SSH tunnel routes internet traffic to your local app:
ssh -N -R 0.0.0.0:8080:127.0.0.1:3000 user@vps.example.com
What you need before using one
A reverse tunnel needs more than the command.
You need:
- A remote SSH server with a public address.
- SSH key access to that server.
- Server-side SSH config that permits remote forwarding.
- Firewall rules that allow the public port.
- A plan for TLS, often through a reverse proxy.
- A cleanup step after the review or test.
If you want a public HTTPS URL, you also need Caddy, nginx, a load balancer, or another TLS terminator on the remote server. SSH will encrypt the tunnel between your machine and the server, but it does not create a polished HTTPS browser URL for reviewers by itself.
That infrastructure overhead is significant for a 20 minute review of a local branch.
When reverse SSH works well
Use a reverse SSH tunnel when you already own the server path and need low-level control.
Good fits include:
- A developer machine behind NAT that must expose a service to a known server.
- Temporary access to a private admin tool during incident work.
- Internal infrastructure tests where the server and firewall are already managed.
- SSH-native teams that want full control over the connection.
When a managed review link fits better
The reverse SSH model puts the server, host key trust, firewall rules, logs, TLS, and teardown in your hands. If the job is “let a client open my local app,” a reverse SSH tunnel makes you solve problems outside the review.
You still need to answer:
- What URL do I send?
- Does it use HTTPS?
- When does access end?
- Can I see if the reviewer joined?
- Can I see failed requests?
- Did I close the port after the call?
wiremaven wraps those answers into the review session. It creates temporary encrypted public links for local dev servers. Your local machine connects through an outbound-only WebSocket relay. The reviewer gets a browser link. You see viewer joins, request outcomes, failures, and the TTL.
npx wiremaven-cli 3000 --expires 30m --name reverse-ssh-alternative
During beta, no account is required. You choose 15, 30, or 60 minute review windows.
Use reverse SSH when you need a server-controlled tunnel. Use wiremaven when you need a controlled review link with less infrastructure work.
Reverse SSH security checklist
Before opening a remote port, check these items:
- Use a dedicated SSH key with a passphrase or constrained access.
- Keep
GatewayPortsscoped to the behavior you need. - Prefer a reverse proxy with HTTPS if browsers will connect.
- Avoid exposing databases, admin panels, and debug endpoints.
- Close the SSH session after the task.
- Remove temporary firewall rules.
- Review logs on the server and the app.
For a local review, the safer default is a time-boxed link. For wiremaven details, see the docs and how wiremaven works.
Reverse SSH versus local forwarding
Local forwarding with ssh -L opens a port on your machine and reaches a remote service. Reverse forwarding with ssh -R opens a port on the remote server and reaches your machine.
Use -L when you need access from your laptop to a private remote resource. Use -R when someone must reach a service on your laptop through a server.
Dynamic forwarding with ssh -D creates a SOCKS proxy. It routes your outbound traffic through the SSH server. It does not expose your local service.
FAQ
What is a reverse SSH tunnel?
A reverse SSH tunnel uses ssh -R to open a listener on a remote SSH server and forward matching traffic back to a service reachable from your local machine.
Why does my reverse SSH tunnel only work on the server?
The SSH server may bind remote forwards to loopback by default. Public access often requires GatewayPorts, an explicit bind address, and firewall rules.
Is a reverse SSH tunnel secure?
The SSH connection is encrypted, but public exposure depends on your server config, firewall, TLS, and app security. Treat a public remote forward as internet-facing access.
Can I use reverse SSH for client reviews?
A review-focused tunnel is the simpler option: it gives a browser link, TTL, and session signals without the server setup and cleanup overhead.
Start with the job
For infrastructure control, practice ssh -R. For a client review, create a short-lived link.
npx wiremaven-cli 3000 --expires 30m
Related: SSH Port Forwarding: Local, Remote, and Dynamic Tunnels | What Is a Localhost Tunnel? | How to Share Localhost with a Client