I also maintain two servers and a desktop machine at home. Through the magic of a DSL line, these machines have static IP addresses and are always connected to the Internet. Sometimes while I'm at work I need to get at a file on my home machine, or I want to check on the server remotely. No problem. I just log in remotely over the Internet to copy files, browse Web logs, or do whatever else I need to do. I can even launch and run X Window applications on one of my home machines, and display them on the desktop at work.
When I'm out of town at conferences, I frequently log in to the office network to check my mail or to look in on things. I do this from my Linux laptop, which I simply plug in to any available Ethernet network.
It's all very convenientand all potentially insecure. If I were using vanilla remote login services, I would be running a horrible risk. The reason is that the simple network protocols that we use every daylike telnet, FTP, and HTTPwere designed in the days when the Internet was smaller and people more trusting. Everything that glides across a telnet, FTP, HTTP, or X Window session is sent "in the clear" without any attempt at encryption or obscuration. This exposes sensitive information, such as passwords, to anyone who has a packet sniffer running on the local network, the remote one, and any of the networks in between. It also exposes users of these protocols to attacks that trick them into providing confidential information to untrusted hosts.
Running X over the Internet is equally foolhardy. Every single keystroke and mouse movement is sent in the clear. Not only can others intercept these keystrokes to read confidential information, but they can also synthesize their own events, fooling my X application into thinking that I typed something I didn't (like the command to delete all files!).
The Problem with Telnet
As a concrete example, consider the telnet protocol, which I might be tempted to use to log in to my home machine from work to check the Web server logs. The telnet client comes standard on UNIX and Windows systems, and a free client is widely deployed on Macintoshes as well. All UNIX systems come with a telnet server that enables remote login across the network. If you happen to have the Windows NT or Windows 2000 Resource Kit CD, you can install a telnet server on your Windows NT or 2000 system, providing remote access to the NT command shell as well.
To prevent any random person from logging in to your system, telnet runs a simple authentication protocol. When it first receives an incoming connection, telnet prompts for a username and password. This information is then compared to information stored in the system user database, and if it matches, the remote user is granted access to the system.
There are two big problems with this authentication protocol. One is that the username and password are sent across the network without any attempt to disguise them from prying eyes. Although we'd like to think that our networks are free of eavesdroppers, experience has shown that you can't take it for granted that any network is secure; not your own, not the remote network, and particularly not any of the networks in between.
Packet sniffers are small programs that examine every item of traffic on a network. They have legitimate uses, such as measuring network loads, or detecting and deflecting denial-of-service attacks, and illegitimate ones, such as intercepting passwords and credit-card numbers as they pass across the network. They are widely available, and difficult to detect.
You might think that you have nothing to worry about because your network is protected behind a firewall and you don't allow incoming connections, but you're wrong. One of your coworkers might be running a packet sniffer for fun, for insurance, or for shadier purposes. Or a coworker might be 100 percent honest, but have the misfortune to have downloaded a trojan horse while at home and brought it into the company network on his or her laptop.
If you think you're safe from packet sniffing because you run switched Ethernet hubs, again you're wrong. The latest generation of packet sniffers, such as the dsniff tool, use the ARP protocol to intercept and examine traffic even in switched networks. In any case, even if your network is as tight as a drum, other networks may not be so lucky; to be safe you should assume that all traffic that passes across the Internet will be examined by a sniffer at least once.
The second problem with telnet's authentication protocol is that it provides no assurance that the remote machine you think you're talking to is bona fide. When you use the telnet program to connect to a remote host, telnet looks up the IP address for the host using the DNS protocol, and then tries to establish a connection. Unfortunately, DNS is rather easily spoofed, and telnet can be fooled into connecting to a rogue machine located somewhere in northeast Bulgaria rather than to the intended host. The rogue machine may present a plausible-looking banner and prompt you for your username and password. After you provide this information, the remote host will simulate a connection failure and drop your login, having just captured your username and password.
Unfortunately the same problems apply to other popular protocols, including FTP for file transfers, the Berkeley rlogin and rcp remote login and file transfer protocols, the POP mail transfer protocol, and the NNTP news transfer protocol.
Cryptography to the Rescue
The correct solution to these problems is to use modern cryptography to secure your remote login and file transfer sessions. Cryptographic protocols can do two things: They can secure the content of a login session so that confidential information isn't transmitted in the clear, and they can dispense with the need for passwords entirely by using public key cryptography to establish the identity of both the user initiating the connection, and the machine he or she is connecting to, with a high level of confidence.
There are various cryptographic protocols that can be used for remote login and file transfer. Microsoft Windows systems have the Point to Point Tunneling Protocol (PPTP) as a standard option. By default, PPTP uses an authentication protocol that avoids transmitting passwords in the clear. It also has an option to turn on end-to-end cryptography, so that the contents of the login session are protected from eavesdroppers, as well. Although primarily intended for use in Windows systems, a variety of PPTP ports for UNIX systems have recently appeared (see " Online").
Unfortunately, the PPTP architecture was designed to support VPNs. It works well for setting up a dialup server, or for connecting two networks across the Internet, but it isn't really appropriate for the many casual logins that I make and break during the course of a day's work. Also, a variety of security holes have lately been discovered in PPTP by independent researcher Bruce Schneier.
The same Secure Sockets Layer (SSL) protocol that secures Web pages has been adapted for use with telnet and FTP. However, these secured versions have never been packaged very well, and are only for the adventuresome.
The Secure Shell
By far my favorite cryptographic protocol for remote login and file transfer is the Secure Shell (SSH). It's remarkably versatile. At its simplest, SSH is a plug-in replacement for telnet, rlogin, and other remote login protocols. Using SSH you can connect to a remote host, log in, get a command shell, and log out just as you would with telnet. However, unlike telnet, SSH uses end-to-end cryptography to secure the communications channel between your machine and the remote one. This means that neither usernames, passwords, nor any other part of the information transmitted back and forth can be intercepted by a packet sniffer.
SSH uses public-key cryptography to authenticate the machine to which you are connecting. Each host that accepts SSH logins has a unique public key known to other hosts in the network, and a matching private key that is secret to that host. Before SSH logs in to a remote host, it cryptographically challenges the host to prove that it knows the private key that matches its known public one. If the remote host can confirm that it does indeed have access to the private key, then the connection is allowed. Otherwise, SSH assumes that the remote host is an impostor, and disallows the connection.
Individual users can use public key-based authentication as well; a set of utilities that comes with with the SSH package lets you create your own public/private key pair and use it in lieu of a password when logging in to a remote host. This is an incredibly handy feature. I travel to a lot of conferences and am always plugging my laptop in to other people's networks. To avoid compromising security, I keep a private key on my laptop that grants me access to my home and office networks. The private key on my laptop lets me log in to any of my home or office machines without providing either username or password. The private key is itself encrypted by a passphrase that I alone know, so that if my laptop were stolen, the key would remain safe.
However, SSH does more than support remote logins. For example, it has a remote copy service that lets you move individual files or entire directories of files back and forth securely. It provides a remote command service that lets you execute a single command on a remote machine.
My favorite feature is SSH's port-forwarding service, which lets you create ad-hoc virtual private networks across the Internet. When you use SSH to connect to a remote machine, you have the option to attach a network port on the local machine to a network port on the remote one. All traffic directed to the local port will be transparently routed through the encrypted channel and appear on the remote end as if it had originated from the remote machine.
A specific example will make the power of this feature apparent. On my office network, there is a development server named turunmaa.cshl.org, and all access to this machine from the outside world is forbidden by a firewall system. Occasionally, when I'm on the road, I need access to this machine to do development work, but how can I get at it with the firewall blocking access?
The answer is SSH forwarding. The main gateway for my organization, a machine called cshl.org, runs an SSH server. From my laptop, I can connect to cshl.org securely and simultaneously establish a proxy to turunmaa with the following command:
% ssh -L
-Lswitch tells SSH to forward all traffic directed to local port 8080 to turunmaa.cshl.org's port 80. This means that I can access the server on turunmaa by pointing my browser at http://localhost:8080.
Because access to 8080 is forwarded to turunmaa.cshl.org port 80, turunmaa's home page will appear on my browser's screen. Because the forwarding goes through an encrypted channel, I don't have to worry about any of the Web pages, cookies, or authentication passwords being sniffed.
SSH lets you create a number of such forwardings, and to group them all together into a configuration file so that they're set up automatically.
SSH and X Window
You can use SSH forwardings with the X Window protocol to encrypt the exchange between local and remote machines and prevent a session from being hijacked. In fact, this feature is so widely used that SSH provides special support for it. When communicating with a remote host that supports X, SSH automatically sets up the appropriate forwardings to let X applications run across an encrypted channel. This makes launching a remote X application as simple as this:
% ssh -f cshl.org gimp
This runs the gimp graphics-manipulation program on the remote machine cshl.org. gimp's windows will display on the local machine and respond to mouse clicks and keystrokes just as if it were running locally. The
-fswitch tells SSH to go into the background after establishing the X Window forwarding and launching the gimp program.
How Safe Is SSH?
SSH uses a modular design that takes advantage of a large variety of encryption systems. Because of differences in national laws, not all encryption systems are available in all countries. For its encrypted channels, SSH supports a variety of ciphers, including DES, triple-DES, IDEA, and Blowfish. For its public/private key authentication, SSH uses the RSA algorithm. SSH allows keys to be as large as the cipher algorithm can handle, giving SSH access to some of the strongest cryptographic systems known to current technology.
The UNIX implementations of SSH are published in source-code form, meaning many people have had the opportunity to scrutinize and test the implementation. Vulnerabilities that existed in early versions of the protocol and implementation were identified and repaired promptly; it has been stable for some time. SSH1, the original version of the protocol, has recently been superseded by SSH2, a version that fixes some ambiguities in the protocol. SSH2 has been submitted to the Internet Engineering Task Force (IETF), where the protocol is currently in the RFC draft stage.
SSH was originally an academic project authored and distributed by Tatu Ylonen of the University of Finland. The SSH source tree was commercialized in 1998 by SSH Communications Security, which sells implementations for both Windows and UNIX systems. The SSH Communications Security FTP site offers downloadable source code and Windows binaries for both SSH1 and SSH2. However, the licensing terms allow only SSH1 to be used without restriction. Commercial enterprises must license SSH2 products on a per-seat basis.
As you might guess, there's also an Open Source implementation of SSH, available from the OpenSSH project. This implementation supports both the SSH1 and SSH2 protocols and has no restrictions on its use. The Open Source implementation is largely compatible with the commercial version, differing mainly in not providing support for IDEA encryption (because of patent restrictions). While the OpenSSH implementation supports only UNIX platforms, other projects provide free SSH1 clients for Windows and Macintosh machines, including PuTTY, TTSSH and FiSSH for Windows, and NiftyTelnet for the Macintosh. The FreeSSH site maintains up-to-date links on various free and Open Source SSH implementations.
A Worry-Free Network?
With SSH installed on all the machines in your network, you can remove telnet, FTP, and rlogin. Will this make your network secure? Well, no. There's a lot more to do to secure a network than merely controlling remote login. But at least you'll be able to use the Internet to its full advantage for remote login without worrying about the consequences.
Lincoln is an M.D. and Ph.D. who designs information systems for the human genome project at Cold Spring Harbor Laboratory in New York. He can be reached at [email protected].