How Secure Shell Tunneling Works

Application streams are tunneled over Secure Shell by forwarding individual TCP ports. In this paper, we focus on local port forwarding: tunnels initiated by the Secure Shell client. This direction is far more common than remote port forwarding: tunnels initiated by the Secure Shell server (see Appendix A).

When a local port is forwarded, SecureCRT® (the Secure Shell client) listens to a specified TCP port on the local host. VShell® (the Secure Shell server) opens a TCP connection to the remote host where the server application is actually running. By convention:

• The localhost refers to the application client's host; remotehost refers to the application server's host. Typically, if localhost is not specified, it defaults to the SecureCRT host. If remotehost is not specified, it defaults to the VShell host.
• The localport refers to the port that the application client sends to and SecureCRT listens to. The remoteport refers to the port that VShell sends to and the application server listens to. In most cases, the localport can be any arbitrary, unused port on the localhost. The remoteport must be the IANA-assigned "well-known" listening port for the application being tunneled.

To use the port forward, the client application must be reconfigured to connect to localhost:localport instead of remotehost:remoteport. Packets sent by the client to localhost:localport are intercepted by SecureCRT or another SSH client, encrypted, and tunneled through the Secure Shell connection to VShell or another SSH server. On receipt, VShell decrypts these packets, relaying them as cleartext through the TCP connection to the server at remotehost:remoteport. Local port forwarding for e-mail is illustrated in Figure 2.

Figure 2: Local Port Forwarding

Traffic in transit between SecureCRT and VShell is cryptographically protected. However, traffic between VShell and the remote host is not. Typically, VShell is located inside the network perimeter, behind a firewall. The firewall is configured to permit Secure Shell, but not the tunneled application protocols (in this example, SMTP, POP, and IMAP). In essence, this configuration relies on the firewall to protect cleartext traffic and inside servers on the trusted LAN.