Illustration of SSH Port Forwarding

Local forwarding is established by option -L.

-L port:host:hostport

Local forwarding specifies that a given port on the local (SSH client) is to be forwarded to given host and hostport on the remote side (through SSH server).

In the figure above, desktop launches the connection to server using command:

ssh -L 2222:target:22 server

Desktop does following things:

1. It establishes the SSH tunnel to server.
2. It is listening on port 2222 during the SSH connection. Any TCP traffic to the port is forwarded to server through the SSH tunnel.
3. It asks server to relay any received forwarded TCP traffic to target:22.

Notice that in argument port:host:hostport, host and hostport are entered on SSH client but are used and resolved in SSH server. For example, -L 8888:localhost:80 forwards TCP traffic to port 80 on the SSH server, because localhost is resolved to itself on the SSH server. This example also shows that server and target can be the same machine.

The local forwarding is useful If server and target are in the same LAN, and only server is exposed to Internet. User logged into desktop wants to connect target using SSH from Internet frequently. Although it is able to log in server first, and then log in target from there in the remote shell. But it requires two authentications, which is tedious. And it forbids some usage such as copying files to target using a GUI sftp client, because we only have a terminal on server.

However, whenever a SSH tunnel is alive and port 2222 on the local is forwarded to target:22 though the tunnel, we can target on desktop simply using

ssh -p 2222 localhost

It looks like there's a SSH server listening on 2222 on desktop. Indeed, the server is target:22.

Remote forwarding sometimes is also referred as reverse forwarding. It specifies that the given port on the remote side (SSH server) is to be forwarded to the given host and port on the local side (SSH client).

In the figure above, server launches the connection to desktop using command:

ssh -L 2222:target:22 desktop

Server does following things:

1. It establishes the SSH tunnel to desktop.
2. It asks desktop to listen on port 2222. Any TCP traffic to that port is forwarded to server through the SSH tunnel.
3. It will relay any received forwarded TCP traffic to target:22 during the SSH connection.

Now in the argument port:host:hostport, host and hostport are entered, used and resolved all in SSH client. For example, -L 8888:localhost:80 forwards TCP traffic to port 80 on the SSH server itself.

The established virtual connection from client to target:22 is the same with the figure in local forwarding, except that now the SSH connection is established by server. This is useful to expose host which is able to connect to other hosts but all income connections are forbidden. For example, server and target are all behind a firewall, no hosts can connect to them from Internet. But server can connect to other hosts though Internet. Using the remote forwarding, TCP traffic to 2222 on desktop now is forwarded to target:22 through tunnel, so it is able to connect target:22 though desktop:2222 now. See the article published on IBM about setting up SSH back door using remote forwarding.

Local forwarding and remote forwarding must specify the final target host and port as arguments. Dynamic forwarding does not need to specify the final target host and port, the TCP traffic is forwarded to SSH server. SSH server depends on the application protocol to determine the destination host and port and then relay to the destination. Currently SOCKS4 and SOCKS5 protocols are supported.

In the figure above, TCP traffic to 2000 on desktop is forwarded to server. But now the destination has not been specified in command arguments, so desktop needs to determine it from application protocol. SOCKS4 and SOCKS5 are just the protocols bringing such destination information. And now port 2000 on desktop can be used as an SOCKS4 or SOCKS5 proxy server.

• Windows can use PuTTY as SSH client.
• Options -f and -N are helpful to keep an alive SSH connection in background. But I use a script to manage the connection in a screen session. SSH collection is closed by server if it is idle for a fixed time, so I send something regularly in the script.
• There are also some SSH tunnel management applications. See MyEnTunnel on Windows and gstm based on GTK.
• You may be interested in how to set up password-free login using SSH.

• man ssh
• SOCKS - Wikipedia
• Secure Shell - Wikipedia

And thanks for the following clip art

• case tower - OpenClipArt
• Cartoon Computer and Desktop - OpenClipArt