SSH Tunneling with Chilkat SshTunnel

SshTunnel provides local SSH port forwarding without launching an external ssh program or a separate tunnel daemon. The application owns the SshTunnel object, while Chilkat creates and manages the background threads that listen for local clients, maintain tunnel activity, and relay data.

Logical traffic path and execution ownership. The local client is commonly a separate process, while the tunnel implementation runs inside the process that created SshTunnel.

Chilkat object or managed thread Separate process or application code SSH server or remote network component Destination service Local-computer boundary

Chilkat implementation model: BeginAccepting starts a listener background thread. Accepted tunnels are managed by a second background thread, the SSH tunnel-pool thread, and active clients are serviced by Chilkat-managed client threads. These are internal threads in the application process.

Four locations to keep separate

Part	Typical location	Execution form	Role
Client application	Local computer	Usually a separate process	Connects to the local listening port or speaks SOCKS to it.
`SshTunnel`	Local computer, inside your application process	Application object plus Chilkat-managed background threads	Listens locally, creates SSH channels, and relays bytes.
SSH server	Remote computer or gateway	Separate SSH server process	Terminates SSH and opens connections to destinations.
Destination service	Remote server, internal host, or sometimes the SSH server itself	Separate server process	Provides the actual database, HTTP, mail, or other TCP service.

What “local” means

“Local port forwarding” describes where the listening socket exists: on the application computer. The client using that socket may be another process on the same computer, another component in the same process, or—when the listener is bound to a non-loopback interface—a client on another computer. For a tunnel intended only for local use, bind the listener to 127.0.0.1.

Choose the forwarding mode

Static local forwarding

Every accepted client connection is forwarded to the same DestHostname and DestPort.

Dynamic forwarding

SshTunnel acts as a local SOCKS4 or SOCKS5 server. Each SOCKS client request chooses its own destination.

Multi-hop SSH

Reach a second SSH server through an already connected and authenticated Ssh object.

SSH through a proxy

Use an HTTP or SOCKS proxy only for the outbound connection from SshTunnel to the SSH server.

Common API sequence

Create the SshTunnel object and set connection, proxy, logging, or binding properties that must apply before connecting.

Call Connect(sshHostname, sshPort), or ConnectThroughSsh for a multi-hop configuration.

Verify the expected SSH host key using HostKeyFingerprint, then authenticate with AuthenticatePw, AuthenticatePk, or another supported authentication method.

Configure static or dynamic forwarding properties.

Call BeginAccepting(listenPort). Check IsAccepting; when port 0 is requested, read the allocated port from ListenPort.

When finished, stop accepting new clients, disconnect active clients as needed, and call CloseTunnel(true) for final shutdown.

Encryption boundary: SSH protects traffic between the local application process and the SSH server. The connection from the SSH server to the final destination is an ordinary TCP connection unless the application protocol itself uses TLS or another form of encryption.