About SSH, RDP and VPN Technologies
SSH is an open source protocol that allows encrypted connections between a client and a server. SSH has many levels of functionality, and what we utilize in this software is the SSH Tunnel. The tunnel allows encrypted, secure communications between the remote client and the SSH server, which will have a single open port exposed to the Internet. The SSH server will then connect to the internal host through the local network. Responses will flow back through the tunnel to the client.
The Microsoft Remote Desktop Protocol is used for remote virtual sessions on Windows. The available sessions can run on Windows NT Terminal Server Edition, Windows 2000 with Terminal Services, Windows 2003 with Terminal Services, and Windows XP with Remote Desktop enabled. When connecting to a server system, RDP allows multiple users remote access to internal systems. Windows XP allows a single user to connect to the system, and will ensure that the monitor, mouse, and keyboard on the system being controlled are locked against viewing.
Most network administrators are very wary against allowing a Microsoft Windows system to be exposed directly to the Internet. This is why VPN (Virtual Private Network) software of many different types are used, typically integrated with the firewall systems. Software such as Checkpoint, Cisco PIX, Raptor, and others allow this system. However, they are all expensive, complex systems. The client installation often involves invasive, low level software that can cause end user home computers to malfunction. Configuration and support can be very difficult. Also, this does not lend itself to installing this software on temporary computers, such as systems owned by friends and relatives when you require remote access from somewhere other than home. Many administrators are running into serious issues when they find out that the VPN software they use is not compatible with the home user's broadband router and its NAT implementation.
Administrators and users of traditional VPN solutions must also worry about the spread of viruses and trojans through the network. A typical VPN configuration means that your home computer can directly talk through TCP/IP, SMTP, and NetBIOS protocols to your internal systems. Many of the advanced clients will require the home user to have anti-virus protection before allowing it to connect. But a virus can spread before signatures are updated. As an administrator, how do you force and enforce end user antivirus installation and configuration?
Other options against proprietary VPN systems are so called SSL VPNs. These run in a web browser. However, they can also be incredibly difficult to manage, and many people have found out that it does not work with their software that they require, and many programs that do have to work inside a web browser, which can also be limiting.
For smaller companies that require an easy to use, but still secure method of remote access, the choices can be limiting. Turning to open source solutions for cost and ease of use is a good option. IPTables and the associated packages that run on Linux make incredibly good firewalls. But that doesn't include a remote access solution. But Linux does include SSH server software.
WiSSH is the perfect solution. Clients at remotely located systems will run this software, and after just as little as two configuration options, entering the name and password, they can connect to the SSH server on the company firewall, successfully authenticate, and then they will tunnel to the company's internal Terminal Server, or even their own Windows XP desktop. Users love this functionality, since they will see exactly what they saw when they left the office. Email, shares, drive letters, printers, everything will work exactly the same as what they are used to. They can even print to the home printer through the tunnel.
WiSSH will only connect to your internal network through port 3389 which has no known ways to spread a virus. And it will only connect to one system, not a spread of addresses, which is how many forms of hostile software spread. The Remote Desktop Protocol typically only will send screen codes, mouse movements, and key presses between systems. The tunnel port on the client is not exposed to the network at all, being an unroutable localhost address.
This software installs quickly and easily without interfering with the home operating system. The initial configuration is very easy. Network administrators can include using private/public key for optional two factor authentication. A custom install can bundle a preconfigured .ini file that will enable any user to just enter a password, click connect, and be productive from home.
Many users of SSH and RDP together, using such products as PuTTY, have had to create various workarounds to make it function correctly. The Microsoft RDP client does not like to connect to localhost. A workaround to this is to change the Compatibility Mode properties of mstsc.exe and mstscax.dll to Windows 98. This will allow the client to connect to localhost. However, if you are connecting to a properly licensed Microsoft Terminal Server, you still will not be able to connect properly. This is because of the license key that is sent from the Terminal Server. This must be stored in the client's registry. However, the registry is not available to programs in Compatibility Mode. WiSSH is able to get past this roadblock and works with Microsoft Terminal Server licensing requirements.
WiSSH Technology Documents
 |
Sample Network Configuration for a small business. The SSH Gateway Server is located on the same system as the firewall. This would be a good example for a company running a firewall on a secured Linux server. After installing, adding a few simple rules will allow the necessary ports from both the Internet and the internal network. |
 |
Sample Network Configuration using a dedicated firewall. This can be as simple as a home firewall router such as a Linksys, to dedicated Cisco, Nokia, and Checkpoint firewall systems. The key to this is that there is no dedicated DMZ area that would require additional rules. Simply allow port 22 to pass from the Internet to your SSH Gateway Server. |
 |
Sample Network Configuration for a DMZ. Most corporate networks will have a dedicated DMZ area. The firewall rules in this circumstance can still be simple. Allowing inbound port 22 into the DMZ SSH Gateway Server, and outbound port 3389 from the Gateway to the internal Terminal Server and/or clients. Another requirement would be for the SSH Gateway Server to resolve the internal hostnames. |
 |
WiSSH Connection Sequence of Events. From the client initiation of the login until disconnection, you can see how the traffic flows between the WiSSH client, the SSH Gateway Server, and the internal host. |
