Securing Network Traffic With SSH Tunnels

Introduction to SSH Tunnels

Secure Shell, or SSH, is used to create a secure channel between a local and remote computer. While SSH is commonly used for secure terminal access and file transfers, it can also be used to create a secure tunnel between computers for forwarding other network connections that are not normally encrypted. SSH tunnels are also useful for allowing outside access to internal network resources.

To create an SSH tunnel, you need:

  • Target server offering network services (http, vnc, etc.) to the client
  • SSH server listening for connections from the client
  • SSH client configured to forward traffic from a local listening port, through the SSH server, to the target server

The SSH server may be running on the same machine as the target server, or on a different machine. Network communications between the SSH server and the target server are NOT encrypted by the SSH tunnel (see diagram below), so if the servers are running on different machines, ideally they should be located together on a secure network.

SSH Tunnel Diagram

Configuring an SSH server is beyond the scope of this article, but popular options include OpenSSH for unix-based systems and Bitvise SSH Server for Windows. The SSH server will need to have access to the listening port on the target server. Common SSH clients include OpenSSH and PuTTY for Windows.

Scenario - Connecting to an insecure service

In this scenario, a client wishes to connect to a service that does not natively use encryption but does not want the traffic to be sent unencrypted through the Internet. The environment for this scenario:

  • Target server: VNC service is listening on port 5900 at IP address 1.2.3.4
  • SSH server: SSH service is listening on port 22 at IP address 1.2.3.5
  • Client machine: SSH and VNC clients installed

Creating the SSH tunnel using PuTTY:

  1. Open the PuTTY client user interface
  2. In the Session window, under "Basic options for your PuTTY session", enter the IP address and listening port for the SSH server:

    PuTTY SSH client

  3. In the left pane, select Connection->SSH->Tunnel
  4. Under "Options controlling SSH port forwarding", enter the following settings (see screenshot):
    • Source port: Pick an arbitrary port, not in use on your client; the example uses 15900.
    • Destination: IP address and listening port for the target server, 1.2.3.4:5900
    • Leave "Local" and "Auto" radio buttons selected
  5. Click "Add" to save these settings
  6. Click "Open" to create the SSH tunnel. Enter your username and password for the SSH server when prompted.

PuTTY SSH client

Creating the SSH tunnel using OpenSSH:

The following command can be used to create the SSH tunnels using the OpenSSH client:

ssh -L 15900:1.2.3.4:5900 1.2.3.5 -N

The option 15900:1.2.3.4:5900 specifies the local port, 15900, to be forwarded to the remote port, 5900, on the target server, 1.2.3.4. The local port can be any arbitrary port not in use on the client. Enter your SSH username and password when prompted, unless you have configured your SSH server for public key authentication.

Connecting to the service through the tunnel:

To connect to the service on the target server, configure your client to connect to the client machine using the local listening port defined in the SSH tunnel configuration. Use the local loopback address, 127.0.0.1 (see screenshot). Traffic will forward through the SSH tunnel to the target server.

VNC

The alternative -- use a client that natively supports SSH tunnels:

Some clients for unencrypted network services, such as FTP, VNC, etc., natively support connections using SSH tunnels. In this case, there is no need to manually create the SSH tunnel using an SSH client such as OpenSSH or PuTTY. Just enter the SSH server information directly into the VNC client supporting SSH tunnels. This screenshot example uses the TightVNC client:

TightVNC

While the example above demonstrates SSH tunnels for VNC, a popular service often configured without requiring encryption, and these same settings can be used to connect to other network services when replacement with an alternative that supports encryption natively is not an option.