Understanding Chilkat’s SSH Tunnel Class

Before Chilkat’s SSH Tunnel, your app would need to connect to a tunnel process/service running either on the local machine or on some computer on the LAN, and then tunnel out to the remote server.  It would look like this:

App ——(1)——>  TunnelService —-(2)——> SshServer —-(3)—–> SomeDestServerSuchAsSQL

You can wrap a non-encrypted TCP connection, or a TLS connection within the SSH Tunnel.
For example, if you connect with TLS, then (1) and (3) are TLS, and (2) is TLS wrapped inside SSH.
The (1) connection is within your LAN, the (3) connection is within the LAN on the server-side, and the (2) connection is over the Internet.

With Chilkat, the TunnelService is no longer a separate service running somewhere on your LAN.
Rather, it’s a background thread of your app.  Thus.. you can run your app anywhere and tunnel without needing to pre-install some SSH tunnel service on the LAN.  (In effect, you’re app is carrying the TunnelService in it’s back pocket..)

Debugging SshTunnel

The Chilkat SshTunnel object/class (may be “CkSshTunnel” in some programming languages) provides a number of properties to help in debugging (i.e. understanding) what is happening in the background thread:

  • AcceptThreadSessionLogPath:  May be set to the path of a log file that the SshTunnel will create and log activity regarding connections accepted.   This will allow you to see incoming connections that have been accepted.
  • ConnectLog: Contains log text detailing the establishment of each SSH server connection.  This log will continue to grow as new connections are accepted.  This property may be cleared by setting it to an empty string.   (This is similar to AcceptThreadSessionLogPath, but it provides information in-memory as a string.)
  • LastErrorText: The standard last-error information that contains information about the last method called.   The LastErrorText contains information regardless of success/failure.
  • TunnelErrors: Contains the accumulated errors, if any, of the background thread.   Call ClearTunnelErrors to clear this string.
  • GetTunnelsXml() — Method that returns information about the current set of running SSH tunnels.  This is a snapshot of the tunnels at a single point in time.
  • TunnelThreadSessionLogPath: May be set to the path of a log file that the SshTunnel will create and log information regarding tunnel activity.

    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 TunnelingIntegrated 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

    SSH Tunneling a Database Connection

    ASP: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    SQL Server: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    C#: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    C++: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    MFC: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    C: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Delphi: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Visual FoxPro: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Java: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Perl: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    PHP: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Python: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Ruby: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    VB.NET: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    Visual Basic: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)

    VBScript: SSH Tunnel for Database Connection (such as ADO, ODBC, etc.)