This UNIX utility provides a secure shell for managing remote servers
Editor's Note: Bret Jordan of the University of Utah provided some configuration file examples and setup information for this article.
Nearly every day, I find myself in a situation that requires me to perform maintenance on some of my servers. That's just life in the Windows world. Usually the situation isn't critical—I need to move a file or restart a service—but because I administer a sizable number of servers, the tasks can be a real hassle. Administering machines that aren't at my office is even worse. A hassle turns into a security nightmare because of the inherent insecurities of most remote shell utilities.
Windows 2000 contains a beefed-up Telnet server, but earlier Windows versions don't provide any built-in remote-management capabilities for command-line use. Systems administrators responsible for managing Windows servers needed some way to issue commands to their servers across the network without using bulky packages such as Windows NT Server 4.0, Terminal Server Edition (WTS) or Symantec's pcAnywhere, so they resorted to various Telnet servers to get the job done. The idea of remote administration tools is good, but using Telnet is a mistake.
Telnet was developed in the early days of the Internet to let users connect to and work on more powerful remote servers. Telnet was developed with ease of use, not security, in mind, so all authentication and data transfer happens in the clear. Any attacker who can sniff network traffic as Telnet sends it across the network or Internet can gather usernames, passwords, and system information. Microsoft has never revised Telnet to include greater security, so the company's choice to include it in Win2K is unfortunate. Shipping Win2K with Win2K Server Terminal Services as the only remote administration option would have been better than including the inadequate Telnet server.
The Microsoft Telnet server makes one attempt at improved security: It supports native NT LAN Manager (NTLM) authentication, which encrypts passwords. You can force the Telnet daemon to accept only NTLM-authenticated passwords and reject others, but this technique is too restrictive for many shops. Win2K allows NTLM authentication by default, but systems administrators often change this value. In addition, NTLM helps only when you connect two Win2K computers that are both configured to allow NTLM authentication. When you telnet to or from a non-Win2K computer, authentication reverts to clear text and your security goes down the drain.
No matter what kind of authentication the Win2K Telnet client uses, Telnet sends all the commands that you issue and the results of those commands across the network in clear text. Thus, when you use Telnet, an attacker can simply sniff your network traffic to gather a lot of information about your systems and network without leaving a trace of his or her activity.
The UNIX world, which has been performing remote administration tasks for a much longer time than the Windows world, has come up with a great solution to Telnet's security problems while still providing the essential service of remote administration. The solution is Secure Shell (SSH). You can use a Windows version of SSH to secure your remote administration tasks.
Enter OpenSSH
SSH is a protocol for establishing secure connections over insecure networks. The second major version of SSH, SSH2, provides for a high level of data encryption and reliable authentication and fixes some of SSH1's inadequacies. SSH2 delivers mechanisms to prevent network sniffing, man-in-the-middle attacks, and encryption cracking. The protocol lets you use a public key infrastructure (PKI) as well as standard password authentication and (most important) is OS-independent. An SSH implementation exists for most major OSs, so you can use the protocol for unparalleled interoperability between platforms.
Several vendors offer implementa-tions of SSH for Windows, but the one I recommend and use is OpenSSH (http://www.openssh.com), which is a free, open-source implementation of SSH1 and SSH2. The OpenBSD Project, which makes the OS of the same name, developed OpenSSH. The OpenBSD programmers have a history of producing extremely secure code, and OpenSSH provides the best current mechanism for seamlessly connecting various platforms in a secure manner. SSH enjoys near universal adoption in the UNIX world, so if you have UNIX computers in your organization, they're most likely using SSH and will be able to talk to any Windows computers running SSH.
Credit for the Win32 port of OpenSSH goes to Cygnus Solutions, the company that originally developed Cygwin (http://www.cygwin.com), a package of popular freeware UNIX utilities that have been ported to Windows. Red Hat purchased Cygnus and now maintains the Cygwin utilities. Cygwin provides intermediary libraries that let code developed for UNIX OSs work in Win2K, NT, or Windows 9x with only minor modifications. Cygwin is an excellent toolkit for any administrator with UNIX experience who is moving into the Windows world.
Get the Tools
You don't need to install the entire Cygwin package on a Windows machine to use OpenSSH. You can download just three packages from one of the Cygwin FTP sites listed at http://www.cygwin.com/mirrors.html: Zlib, Cygwin, and Openssh. Zlib is used for compression. Cygwin contains the file cygwin1.dll, which lets OpenSSH run under Windows, as well as a few useful utilities. Openssh contains the SSH software. Note that this is not a support installation of Cygwin, so your mileage may vary.
On the FTP server, you'll find subdirectories containing the various Cygwin components. Each subfolder holds various versions of both the source and compiled code. The source files (which you don't need) include src in their name. Download the most recent versions of the non&—source code components. At the time of this writing, the files were /latest/zlib-1.1.3-6.tar.gz, /latest/cygwin/cygwin-1.3.2-1.tar.bz2, and/latest/openssh/openssh-2.9p2-3.tar.bz2.
Files ending in .tar.gz are similar to Windows .zip files. They're compressed archives, and recent versions of WinZip Computing's WinZip know how to unpack them. WinZip won’t be able to open files that end in bz2, however. For that, you should go to http://sources.redhat.com/bzip2 and download the bzip2 utility. Once you have decompressed the bz2 file (e.g., bzip2 –d file), you can open the remaining tar file with WinZip. Before unpacking any files, create a base directory to hold the executables. You can put the directory wherever it's most convenient for you; for this article, I use C:\ssh. Open the cygwinxxx.tar.bz2 archive, and extract the cygwin1.dll file to C:\ssh. Then, open the zlibxxx.tar.bz2 archive and extract the cygz.dll file to C:\ssh. Finally, open the opensshxxx.tar.bz2 archive, and extract the ssh-keygen.exe and ssh.exe files to C:\ssh. For server installations, extract sshd.exe, too.