Use SSH to secure remote admin
Published: 17 Mar 2003 11:56 GMT
The TightVNC enhancement to the original VNC freeware application from AT&T research labs in the UK adds secure communication channels for remote administration sessions. TightVNC secures these communication channels using Secure Shell (SSH).
Unix and Linux administrators have used SSH for years, and now Windows administrators can take advantage of it using TightVNC. To demonstrate how it works, I'll show you how to implement TightVNC and SSH on a Windows NT server. You can use the same logic to secure communications on other TightVNC supported systems.
First though, a few words on SSH. Not only does SSH encrypt authentication parameters, it also encrypts all the session traffic. SSH is meant to replace insecure session protocols such as telnet, rsh, and rlogin. It allows the secure movement of data and files across insecure channels, (e.g., the Internet). In the case of TightVNC, SSH can secure remote administration commands.
SSH is in widespread use across 60 or more countries. SSH comes in two flavors, SSH1 and SSH2. Both encrypt different parts of a packet. Both are different protocols -- SSH2 is basically a rewrite of SSH1 with improvements in security, portability, and performance. SSH1 is no longer under development, but SSH2 is still being developed.
SSH on NT
In terms of licensing, noncommercial use of SSH is generally free. But if you're going to use SSH commercially, you should buy the software. There are various vendors including SSH Communications Security and VanDyke Software.
Although it's outside of the scope of this article, installing an SSH daemon onto an NT box is pretty straightforward -- you can refer to the vendor's documentation for this. Once you have the SSH NT server host up and running, you'll also need an SSH client on the administration workstation you'll use to access the remote sites.
Securing the link
Start off by installing the TightVNC server on your target server or workstation and the TightVNC client on your administration workstation. For details about how to do this, see the article "Remote administration -- with security!" Test the communications on an unsecured channel between the server and workstation to make sure that VNC works properly.
After you've confirmed that everything works, you must make a change to TightVNC's Advanced Properties. Double-click the TightVNC icon in the system tray. When the dialog box opens, select the Advanced button. In the Advanced Properties dialog box, be sure to check the Allow Loopback Connections and Allow Only Loopback Connections check boxes, as shown in Figure A. This ensures that TightVNC works through only the SSH secure pipe.
| Figure A |
![]() |
| Set loopback connections to allow TightVNC to use secure channels. |
Once you're up and running with TightVNC in loopback mode, and both the SSH daemon and client are installed, you can initiate a secure session. When you do this, a dummy server will be created on your client machine that listens on the VNC port and moves all connections to that port into the SSH tunnel. The SSH tunnel in turn transports the connections to the remote server. Because you've selected the loopback mode above, TightVNC will think that the connection is a local one and allow a secure session to be built. Your remote admin traffic will then be secure.
Final thoughts
SSH can be used through firewalls, and you can also use it to protect FTP, POP, and IMAP sessions going through a firewall. Most SSH sessions through a firewall use port 22, but you can change this to go through another open port on the firewall, such as SSL port 443, which is usually open anyway.
For a weekly round-up of the enterprise IT news, sign up for the Enterprise newsletter.
Tell us what you think in the Enterprise Mailroom.












