Remote port forwarding in PuTTY exposes a TCP port on an SSH server and securely carries incoming connections back to a service running on a Windows PC. It is commonly used to publish a local development site, API, or database listener into a remote environment when direct inbound access is blocked by NAT, firewalls, or provider restrictions.
An SSH remote port forward (similar to ssh -R in OpenSSH) asks the server-side sshd process to listen on a chosen port and forward each inbound connection through the encrypted session to the client. The client then connects to the configured destination host:port from the client’s network perspective. PuTTY configures this under Connection → SSH → Tunnels and activates it when the session connects.
Remote forwarding must be permitted by the SSH server policy (for example AllowTcpForwarding or PermitListen in OpenSSH) and may be restricted to loopback-only binds unless GatewayPorts is enabled and the client requests a non-local bind. Binding the remote port to non-loopback interfaces increases exposure, so prefer localhost-only access unless there is a clear requirement for wider reach. The forward exists only while the PuTTY session remains connected, so closing the window drops the tunnel.
Example: 18080 makes the SSH server listen on TCP port 18080.
Example: 127.0.0.1:8080 forwards incoming remote connections to TCP port 8080 on the PC running PuTTY.
Non-loopback remote binds can expose the destination service to the network; keep this disabled unless required and confirm the SSH server allows it (for example GatewayPorts).
A typical entry looks like R18080 127.0.0.1:8080.
Accepting an unexpected fingerprint can indicate a man-in-the-middle attack or a connection to the wrong host.
Remote port forwarding from 127.0.0.1:18080 enabled Remote port forwarding from 0.0.0.0:18080 refused
A refusal typically means server policy blocks forwarding or the remote port is already in use.
$ nc -vz 127.0.0.1 18080 Connection to 127.0.0.1 18080 port [tcp/*] succeeded!
The destination service must be listening on the configured Destination for the connection to succeed.