Tutorial on using VNC and SSH to access a windows PC behind a UNIX or Linux firewall

Joey Kelly <joey@joeykelly.net>

November 12, 2002

Introduction

This document assumes that the user is on a windows PC and is trying to connect and control another windows PC that resides behind a UNIX or Linux firewall. An example of this kind of scenario is the office worker that needs to access his office computer while at home (perhaps he is out sick, or has gotten permission from his boss to telecommute).

This technique described in this document also works with Apple computers If the user wants to use Apple, simply substitute Widows for Apple in the following explanation. Since the author doesn't use Apple computers, this document will not go into detail about setting it up.

In similar situations, the user often uses a program such as PC Anywhere or Timbuktu to do this, but in the scenario we are describing, these types of programs cannot easily be made to work,

either because of the existence of the firewall or because of the lack of built-in security in some of these types of programs. Additionally there is the issue of cost: PC Anywhere sells for around $150 USD, while the tools we will use are free of charge.

For the rest of this document, we will be using this scenario (home user connecting to an office PC residing behind a UNIX firewall).

Before We Begin

Most PC users have never used a Linux firewall or server before, and are perhaps a little apprehensive at doing so. However, all of the configuration needed to access a PC that is behind a firewall is done on the user's windows PC. No UNIX commands need to be run, as all of the

configuration is done in programs that run on the familiar windows platform.

For this type of setup, it is required that the user obtain a "shell account" from the firewall administrator. Without this, the user still has the possibility of being able to connect to his office PC, but all of his data will be sent "in the clear" and available to Internet hackers to peruse at their pleasure.

Since we don't want to let that happen, we send all of our data between the two PCs in an encrypted form, which renders useless any data the hacker is able to capture. All the evil hacker sees is meaningless strings of text and/or garbage, while we continue to do our work uninterrupted and safe from his prying eyes.

Our Tools

Our PC-Anywhere substitute that we will be using is called VNC (http://www.realvnc.com), which stands for "Virtual Network Computing", which was developed by AT&T Labs. VNC comes in two parts: the server (WinVNC) which runs on the target PC, in this case the PC at the office, and the viewer (VNC Viewer) which the remote user runs on his PC at home. VNC is a highly useful tool, and will allow Windows, UNIX and Apple computers to work together painlessly. The author manages a 100+ user network in three states and is able to remotely administrate them without ever leaving his chair.

VNC is easy to set up. The server is loaded onto the target PC and is started. The user is then prompted for a password. It is advisable to make VNC run as a service on Windows NT, XP or 2000 PCs. Placing a shortcut to the WinVNC icon in the Startup folder on Windows 95/98 PCs is sufficient, however.

Once the server is running on the target PC, the user can then access that PC's desktop from any other workstation in his office. This is done with the viewer. When VNC Viewer is started, it asks for the name or IP address of the target computer (the one that the VNC server is running on). After this is correctly typed in, the user is then prompted for the password that he set earlier. If everything up to this point was performed correctly, the user should see a window open, which contains the desktop of the target computer. Neat, huh?

Once we have verified that everything is set up correctly, we can then attempt to set up the user's PC at home. Basically, everything works the same, except we first need to set up an encrypted channel from the PC at home to the firewall at work, and to the target PC behind the firewall. This is accomplished with an SSH client, which runs on the PC at home. There are several windows SSH clients to choose from, but we are going to use a program called PuTTY.(http://www.chiark.greenend.org.uk/~sgtatham/putty/), which is probably the most user-
friendly choice available. One of the nice things about PuTTY is that it fits on a floppy along with VNC Viewer and can be used anywhere the user can find a connection to the Internet, such as at a client's office, at the library, or while on vacation, etc..

A Little Networking Theory

While the user can follow the directions for setting up PuTTY and make it work without understanding what is going on, it might be helpful to have at least a basic understanding of the network principles involved. The user may of course skip this section if he desires.

The Internet and most corporate LANs use TCP/IP as their primary networking protocol. Basically, TCP/IP determines the address or location of each computer, as well as what services are available on each computer or server. A computer's location information is known as it IP address, and may have an associated domain name as well. A computer's IP address and associated routing information tells other computers how to reach it.

Furthermore, TCP/IP keeps track of what port a service runs on and enables other computers to interact with it. As an analogy, a port is sort of like a door on a house or office building. Visitors to your office normally use the front door to enter your office building, but delivery people carrying large boxes know to use the loading dock. Similarly, a web server normally is assigned to operate on port 80, and users accessing web sites will point their browser (Netscape or IE) at port 80 in order to receive the data that comprises a web page. Of course, this is all transparent to the user, since the default web port is known to all computers. Similarly, email, online chat, file sharing, streaming audio, etc. all use certain ports set aside for each type of service. Many different services can run on an Internet server at the same time, and knowing which port to use keeps all of the services separated and the client software from becoming confused.

Earlier we mentioned firewalls and encryption. Security is a big deal on the Internet these days, and it is important to keep our data safe. A firewall is a piece of hardware or software that stands between a computer or LAN and the Internet, watching to make sure that no data escapes and no hacker intrudes. A firewall acts like a filter, selectively allowing or denying access to certain IP addresses and ports. Encryption, on the other hand, scrambles data so that is cannot be read by others. The intended recipient is able to unscramble the data and make sense of it, but hackers cannot, and are foiled.

How does all of this fit in to our scenario? We will use PuTTY to connect to the office firewall, and from there construct an encrypted tunnel to our office PC. The far end of the tunnel will automatically connect to WinVNC running on the office PC. We will then use VNC Viewer at home to connect to the near end of the tunnel, and our remote desktop will be available to the user at home.

WinVNC normally runs on port 5900, and the SSH tunnel will pipe port 5900 on the home PC through the firewall to port 5900 at the office to the PC there. The user then uses VNC Viewer to connect to the PC at home, on port 5900. Remember, the user is not running the server WinVNC on the PC at home, but that port now exists on the home PC. The port and the VNC service originates at the office, but using SSH port forwarding constructs a pipe between the office and home computers. The user connects to the near end of the tunnel, port 5900 on his home PC, and the other end of the tunnel appears as port 5900 on the office computer. All data passing through the tunnel is encrypted and secured from prying eyes. This is the magic of SSH and port forwarding.

Configuring PuTTY

PuTTY doesn't have an installer program (it's just a single executable), so the user can place it anywhere on his system and place a shortcut to it. The author usually places putty.exe in C:\Windows or C:\WINNT on an NT or 2000 computer so it's in his path, but the user can place putty.exe on his desktop if he likes.

Once PuTTY is started, the user is prompted to enter a hostname or IP address. This would be the domain name or IP address of the company firewall. The protocol needed for this to work is of course SSH. It is advisable to name this session and save it in the Saved Sessions box.

Once this is done, a connection to the firewall can be initiated by clicking "Open". If all goes well, a black window will appear on the users's desktop with a username prompt, and a windows alert box will appear, telling the user that the host's key isn't cached in the registry (or some message to that effect). The user should click yes here. This is an important security checkpoint which will be explained at the end of this document. The alert box will disappear, leaving the black window open showing the username prompt.

At the prompt the username issued by the firewall administrator should entered. Next, a password prompt will appear, and should be entered. Case is important here! If the username and password were entered correctly, the user will see perhaps a bit of text from the firewall administrator containing news about the server, a funny quote, or some other banner, and finally a command prompt. Once the user has successfully logged on to the firewall for the first time, he should then exit the "shell" by typing "exit" or by clicking the "X" to close the PuTTY window.

Once the user has tested his ability to log on to the firewall shell account, he can then set up port forwarding. This is done by starting PuTTY again, selecting the saved session, and clicking "Load". Clicking on the category marked "Connection" ... "SSH" ... "Tunnels" will bring the user to the port forwarding setup screen. Clicking the "Add' button will allow the user to enter the required information.

The source port is 5900. The destination is the IP address of the target PC at the office and the vnc port (5900), separated by a colon. An example of this would be as follows: assuming the IP address of the target windows PC in the office is 10.0.0.25, the string the use would enter in the destination field would be "10.0.0.25:5900". Once this is entered, the user can click back to the session category and click save.

Putting It All Together

The user is now ready to connect to his office desktop. The user should log on to the firewall as he did during the initial test. Once he is logged on, he can then start VNC Viewer, putting in a special IP address that signifies his home PC (or any PC the user is physically sitting at and using). He can put in either the IP address "127.0.0.1" or he can use the hostname "localhost". If all has gone well up to this point, he will be prompted for the VNC password he set up initially when he was at the office. Once this is entered, the office desktop will appear in the VNC Viewer window. The user can then work on his office PC as though he were sitting at the office in person. When the user is finished working, he can close the VNC Viewer window and close the SSH connection, either by typing "exit" at the command prompt or by closing the PuTTY window as before.

Final Thoughts

As with other types of networking programs, sometimes the user's connection gets dropped. When this happens, the mouse or keyboard inside the VNC Viewer window will stop responding, or perhaps a message will pop up, or the VNC window will close altogether. When this happens, the user should close both of the windows (VNC Viewer and PuTTY) and restart the logon procedures. The user will find that no data on the office computer has been lost. This is because the only thing being transferred between the office and home computers is the image of the remote desktop. No files or other data travel over the Internet, so nothing can be lost. This is of course identical in function to PC Anywhere or other remote desktop applications.

Additional options in PuTTY include sending "keepalive" packets, found under the "Connection" branch of the options category tree. Also useful is data compression and using SSH version 2 as the preferred connection method. Both of these options are listed in the SSH branch. Compression is useful on dialup or other slow links, but can be enabled full-time, while version 2 of SSH is more secure than version 1. Upon switching to version 2 the user will be prompted to save another host key to the registry, as the keys for version 1 and 2 are different. The user should save the session once he is finished editing the configuration.

As a final note, if the user tries to log on to the office firewall and gets a popup alert saying that the host keys don't match, the user should stop trying to connect and immediately contact his firewall administrator. This is a security checkpoint that should not be disregarded, as this can be a sign of a "man-in-the-middle attack" by an evil hacker. It is also possible that the firewall administrator has been doing maintenance on the firewall or some other server. The only way to be sure and remain safe is to verify this with the firewall administrator. More information about SSH can be found at http://www.ssh.com/ or at http://openssh.org/.