Tunneling with SSH

Windows to UNIX connectivity in a secure world

Use OpenSource tools, such as Secure Shell (SSH), PuTTY, and Cygwin, to create secure connections to almost any resource you need to access. Current information on SSH tunneling and setup is fragmented and limited to specific applications, or it is written at a system administrator's level. With increasing security needs, the addition of boundary firewalls, and tightening of the number of allowed network ports, users need a method that is simple to configure, easy to operate and, above all, secure to accomplish day-to-day tasks and access the services that they have become accustomed to.

In my day-to-day work, I have found that many users are frustrated by new security imperatives imposed by network managers. Although users understand the need for additional security, these restrictions cause significant bottlenecks to productivity. While these users are technically literate, network services setup and firewalls are not a normal part of their knowledgebase.

This article describes the setup of a simple SSH client connecting to an AIX®- or Linux®-based SSH server that allows a typical, technically literate individual the ability to set up, configure, and operate a flexible means of tunneling data and services over the SSH service. Users will benefit from having control of their own environment and the ability to adapt to their day-to-day needs. Administrators will benefit from reduced user requests to open ports and tighter control of their secure environments as a result.


James E. Shewbert (shewbert@us.ibm.com), Staff Software Engineer, IBM

Photo of James ShewbertJames Shewbert joined IBM in 2002 after graduating from Texas Tech University with an MSBA in information systems. Since that time, he has worked as a tester and automation technology lead in the Global TIM Competency on a variety of projects, including the ManageNow/eESM suite. He is also a Sun Certified Programmer for the Java™ 2 environment.

17 October 2006

Also available in Chinese


With new security threats cropping up every day, network managers are understandably protective of their computing assets. Enhanced security measures, however, can inflict significant hardships on legitimate users and can lead to frustration, productivity losses, and dangerous attempts at circumvention of restrictions. Equipping yourself with proper tools for connectivity can make your tasks easier while still maintaining network security and integrity. One of the most valuable tools in the IT toolkit is Secure Shell (SSH). Using SSH as a replacement for Telnet is familiar to most users, but many are unaware of its other benefits. When properly configured, a server and client can connect and communicate virtually any service using the SSH link. And, since SSH is inherently more secure than Telnet, FTP, or other unencrypted protocols, most network managers are accommodating to requests to open ports and allow SSH communications through the firewall. The following is a summary of the techniques that I have used to make connectivity through firewalls both effective and secure.

Setting up an SSH client

What you need to start:

  • Make sure you have a Windows® host (referred to as the SSH client) and SSH client software (such as PuTTY).
  • An SSH server (referred to as the SSH server) is required -- typically inside a firewall-protected network zone, the servers are usually based on AIX®, Linux®, or other UNIX® variant, but Windows-based SSH servers can also be used.
  • Additional server processes (Server Message Block (SMB), Virtual Network Computing (VNC), and so forth) are also needed, as appropriate.

Setting up an SSH server

Most current distributions of UNIX-type operating systems include some variant of the OpenSSH software. If your particular distribution did not come with it, you can check the OpenSSH site (see Resources) for binaries or source code. In most cases, installing the server is as simple as installing a Redhat Package Manager (RPM) and verifying the configurations settings. The exact installation method varies, depending upon the specifics of your environment. In practice, OpenSSH is installed by default in most modern UNIX systems.

Given its popularity, the following description uses the free SSH client, PuTTY, as a reference. The configuration is relatively generic, however, and the choice of clients is up to the user. The foregoing configuration steps assume a familiarity with basic SSH connections and provide detail on establishing connections to tunneled services.

Figure 1 illustrates the basic concepts of forwarding a basic VNC connection over an SSH tunnel.

Figure 1. Forwarding a basic VNC connection over an SSH tunnel
Forwarding a basic VNC connection over an SSH tunnel


  1. Ensure that no services are running on the local port that you will be connecting to on the remote server. In subsequent steps, you will use an SSH client to define a virtual service on your local client that corresponds to the services you would like to access on the remote systems; therefore, the local ports that correspond to the remote ports must be available. For example, if you will be attempting to access an SMB share on a remote system using tunneling, you must disable File and Printer Sharing for Microsoft® Networks on the local system. Similarly, if you intend to attach to a VNC server on a remote host, you must ensure that if any VNC server sessions are running on the local system, they are not on the same port as those on the remote system to which you are connecting.
  2. On the client workstation, create a standard SSH connection profile to connect to the remote host. The following example assumes that you are using the free PuTTY SSH client; however, the principal is the same regardless of the client you choose.

Alternate usage for command line or Linux client users

Users preferring other clients, such as OpenSSH or users on other IX-based clients, can use the following command line to achieve the same effect as the PuTTY configuration depicted in Figure 2:
ssh -L 5900:localhost:5900 Server1_host_name

Figure 2. Alternate PuTTY configuration
Alternate PuTTY configuration
  1. After entering the information in Figure 2 above, be sure to select the Session item from the Category tree and save the session for future use.
  2. On the Client workstation, open the session created above. You will be prompted to confirm the addition of the server's key to your local key store the first time a connection is established between a client and server. Once you have reviewed and accepted the remote server's key, supply the user ID and password for the remote server. When you receive a command prompt on the remote system, your SSH connection and tunnel are ready for use.
  3. On the Client workstation, launch the VNC viewer software and enter the localhost:5900 in the VNC server field, as shown in Figure 3 below, and then click Connect. The connection window's appearance will vary depending upon the version of the VNC in use; however, the principle is the same.
    Figure 3. VNC options
    VNC options
  4. In a few seconds, you should see the VNC window. The systems are now conducting a VNC session through the SSH link.

Advanced topics

Once you have established the basic connection detailed above, you can repeat the pattern to tunnel any service for which you can identify the port configuration. In addition, forwarding can be configured to access multiple services and additional servers within the secured zone using a single link. In the following example, the SSH client connects to the SSH server, just as in the previous example. In addition, the SSH client is configured to forward an additional port (139) to another remote server. Note that the remote server needs no special configuration or software for this configuration to function, and the configuration is independent of the operating system: The SSH function serves merely as a conduit for the communication. The SSH server configuration from the previous example is depicted below, with the new configuration items in blue. This allows the client to access several servers and services through the use of a single, secure port, simultaneously. Figure 4 illustrates how such a connection can be used.

Figure 4. SSH server configuration
SSH server configuration

Two of the more common ports are:

  • Windows File Sharing: 139
  • Windows Remote Desktop Protocol: 3389

This is not an exhaustive list; as noted above, most network services for which a port can be identified can be forwarded in this manner.


  1. Following the steps in the previous section, add an additional forwarded port to the PuTTY Configuration window, as depicted below. Figure 5 illustrates the definition of a tunnel for Windows File sharing.
    Figure 5. Windows file sharing
    Windows file sharing
  2. After defining the tunnel and saving the profile, open the SSH session and log in to Server 1.
  3. On the local Windows Client, open a Windows Explorer session and enter \\localhost\sharename_on_Server2 and press Enter.
  4. After a few seconds, you should receive a password prompt requesting login credentials for the remote share. Enter the username and password for the share on Server 2.
  5. After a few seconds more, the window will refresh and present a listing of the files present on the share.

X11 forwarding

One of the more esoteric uses of SSH, X11 forwarding, allows the graphics portion of an application to be rendered on the SSH client while the logic executes on a remote server. By using such a method, users can avoid the network overhead of forwarding an entire desktop over the link and receive only the relevant portions of the display. Figure 6 depicts the basic scenario for X11 forwarding.

Figure 6. X11 forwarding
X11 forwarding

What you need:

  • One Windows host (referred to as the SSH client) X server and SSH client (such as Cygwin-X)
  • One SSH server (referred to as the SSH server) -- SSH server software installed and operating (*IX: OpenSSH)
  • Any graphical server applications


To configure an X server on your local Windows workstation, access the Cygwin setup program. The default installation installs the Cygwin-X packages. Once the default installation completes, execute the following steps to enable forwarding of the GUI display to your local system.

  1. On the remote SSH server, find the sshd_config file. Typically, this file will reside in /etc/ssh/, but the location might vary depending upon your specific operating system or distribution.
  2. Edit sshd_config and find the line containing X11Forwarding, similar to the example below:
    #AllowTcpForwarding yes
    #GatewayPorts no
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    #PrintMotd yes

    Ensure that the line is identical to the example above when you finish editing it. It should not be preceded by a comment mark (#), and its value should be set to Yes. If it is necessary to make changes to the sshd_config file, you must restart the SSH subsystem.
  3. On the local SSH client, find the ssh_config file. On systems configured with CygwinX, the file resides in /cygdrive/c/cygwin/etc/.
  4. Edit ssh_config and find the following line:
    #Host *
    #ForwardAgent no
     ForwardX11 yes 
    #RhostsRSAAuthentication no
    #RSAAuthentication yes

    Ensure that the line is identical to the example above when you finish editing it. It should not be preceded by a comment mark (#), and its value should be set to Yes. If it is necessary to make changes to the ssh_config file, you must restart any active SSH sessions for the changes to go into effect.
  5. On the local SSH client, start the X server by executing<cygwin home>\usr\X11R6\bin\startxwin.bat. After a few seconds, a command shell window appears.
  6. In the command shell window, initiate a standard SSH connection to the SSH server that you have configured in the previous steps. The command takes the form ssh user@hostname.domain.
  7. Once you have successfully logged in and have access to the remote machine, you can then execute any application with a graphical component and the graphical portion will display on the SSH client's display. To verify quickly that the link has been correctly established, type xclock to launch the standard X Window clock utility. You should immediately see a window with an analog clock face appear, as shown in Figure 7.
    Figure 7: The xclock and the DB2® Control Center
    In the example, both xclock and the DB2 Control Center windows appear on the windows desktop.


Although you cannot eliminate the inconveniences associated with increased security measures, you can reduce their impact on productivity. Through the use of commonly available or OpenSource tools, such as SSH, PuTTY, and Cygwin, users can create simple, secure connections to almost any resource they need to access. By encouraging the use of the techniques described above, network managers can ensure that users comply with security requirements while permitting them a higher level of control over their daily activities.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks

Zone=AIX and UNIX
ArticleTitle=Tunneling with SSH