SSH Tunneling (Port Forwarding)

SSH Port Forwarding (or tunneling) allows you to tunnel any TCP connection through an SSH server. For example, consider a database connection:

A direct TCP connection:

DbClient <----TCP---->  DbServer

An SSH tunneled connection:

DbClient <----TCP----> SshClient <====SSH====> SshServer <----TCP----> DbServer

In a tunneled connection, the application connects through an SshClient to an SSH server and starts a direct-tcpip channel, specifying the destination host:port (i.e. the database server). Historically, the SshClient has been a standalone program, such as PuTTY, that typically runs on the same computer as the DbClient. We’ll show you later in this article how the SshClient is merged directly into your application to eliminate the need for a standalone SSH go-between to be running wherever your application runs. This is the power of Chilkat SSH tunneling: your application can create tunnels without requiring external software such as PuTTY to be installed and running.

The SSH Server may run on the same computer as the DbServer, or anywhere else. The typical situation is that both the SSH server and database server are within the same firewall. The firewall typically allows traffic to pass through port 22 to the SSH server, but not to the database server. Communications between the SSH server and database server are not secure, but since they occur behind a firewall, it’s not a problem.

A tunnel can be established to anything, not just a database server. For example:

HttpClient <----TCP----> SshClient <====SSH====> SshServer <----TCP----> HTTP Web Server
SmtpClient <----TCP----> SshClient <====SSH====> SshServer <----TCP----> SMTP Email Server
Pop3Client <----TCP----> SshClient <====SSH====> SshServer <----TCP----> POP3 Email Server
ImapClient <----TCP----> SshClient <====SSH====> SshServer <----TCP----> IMAP Email Server
TcpClient <----TCP----> SshClient <====SSH====> SshServer <----TCP----> Custom TCP Socket Application

Prior to Chilkat, SSH tunneling required a separate client-side program (or Windows Service) to serve as the SSH2 port forwarding client. (This is the SshClient in the diagram above.) This is an added piece of infrastructure that must be installed and running in order for your application to use SSH tunneling. This adds complexity to your application’s deployment, is a potential source of failure, and represents a hidden cost of ongoing support for your application. (Chilkat always recommends minimizing infrastructure and complexity.)

Chilkat provides three solutions to merge the SshClient directly into your application:

1. Integration with the protocol API. Chilkat’s API’s for SMTP, POP3, and IMAP have been extended with SSH tunneling methods. Using an SSH tunnel with these API’s is simple: Establish the SSH tunnel by calling SshTunnel(hostname,port), then authenticate by calling SshAuthenticatePw(login,password). This creates the tunnel, and the remainder of the IMAP, POP3, or SMTP programming is identical to the non SSH-tunnel case. (See the following examples: Integrated POP3 SSH Tunneling,  Integrated SMTP SSH Tunneling, Integrated IMAP SSH Tunneling.
2. Use the Chilkat SshTunnel class/object to create the “SshClient” in a background thread of the application. This is a good solution when using non-Chilkat API’s that require a hostname:port for a connection, such as with database programming (ADO, ODBC, OLE DB, etc.) Your application would instantiate an SshTunnel object, set various properties (SSH server hostname/port, database server hostname/port, SSH login, etc.) then then start the background thread by calling SshTunnel.BeginAccepting. The SshTunnel runs autonomously in a background thread, accepting connections and managing bi-directional SSH tunnels. Here are examples:  Background Thread SSH Tunneling
3. Use Chilkat SSH to create a direct-tcpip channel via the Ssh.OpenDirectTcpIpChannel method. Your application may then send and receive data through the SSH tunnel by calling various Chilkat SSH send/receive methods. This solution is good for when the destination server is a custom TCP socket server (i.e. it uses a custom application-specific protocol that you’ve designed).  Here are examples: direct-tcpip Port Forwarding