Usually an SSH SOCKS tunnel gives a laptop the server's network exit. Reverse dynamic forwarding reverses that arrangement: a program on the remote machine can use the network available to your SSH client.

On an OpenSSH client supporting destination-less remote forwarding:

ssh -N -R 127.0.0.1:1080 [email protected]

The SOCKS listener is on remote.example.net, bound to its loopback address. Programs there use 127.0.0.1:1080. Destination connections travel back through SSH and are opened from the side running your client.

Read the direction before the IP

The -R documentation makes the omitted destination significant. A specification containing port:host:hostport is a fixed forward instead. Do not assume an old client supports the shorter dynamic form.

The outward IP is whatever your client-side network uses for those connections. A laptop behind a home router may leave through the router's translated public address. It is not automatically the SSH server's IP, or an address assigned directly to the laptop.

Keep the remote listener restricted. A wildcard binding can let other machines use your client-side network as an exit, subject to server policy. Even loopback can be available to other eligible processes on the remote host; it is not a per-process secret.

For a restricted destination set, review PermitRemoteOpen and the server's forwarding policy. The route also depends on your client remaining online. When that connection closes, the remote proxy path disappears. Reverse forwarding changes where connections originate; it does not provide a standalone proxy independent of the SSH session.

Related articles