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.
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.
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
- 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.
- 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.
|
Figure 2. Alternate PuTTY configuration
- 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.
- 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.
- On the Client workstation, launch the VNC viewer software and enter the
localhost:5900in 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
- In a few seconds, you should see the VNC window. The systems are now conducting a VNC session through the SSH link.
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
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.
- 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
- After defining the tunnel and saving the profile, open the SSH session and log in to Server 1.
- On the local Windows Client, open a Windows Explorer session and enter
\\localhost\sharename_on_Server2and press Enter. - 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.
- After a few seconds more, the window will refresh and present a listing of the files present on the share.
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
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.
- 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.
- 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. - On the local SSH client, find the ssh_config file. On systems configured with CygwinX, the file resides in /cygdrive/c/cygwin/etc/.
- 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. - 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. - 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.
- 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
xclockto 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


