7.1. Introduction

Historically, telnet, ftp, and the BSD r-commands (rcp, rsh, rexec, and rlogin) have been used to handle interactive sessions and file transfers between a local and a remote host. Although these utilities are still popular and in widespread use, their severe security problems make them unsuitable for use in settings where security is a concern. For example, telnet and ftp provide no encryption or authentication services, so any data transferred using them is vulnerable to eavesdroppers using simple passive attacks. More seriously, these utilities send the user's password as plaintext, allowing the attacker to recover it and subsequently log on to the remote system as the user.

The r-commands are even worse. They share the same problems as telnet and ftp and are often configured to use a convenience mode that does not require the user to present any credentials. This mode is easily subverted to allow an attacker on any machine to log on to or run commands on the target machine as any user authorized to use the r-commands.

The Secure Shell (SSH) suite is a set of programs that serve as drop-in replacements for telnet, ftp, and the r-commands.

More accurately, SSH is a set of protocols. Because their most popular implementations are the UNIX programs ssh and sshd, most users think of SSH as its implementation rather than the underlying protocols.

Despite its name, SSH has nothing to do with a shell, such as sh, csh, or bash. Rather, SSH provides a secure connection over which a user may, among other things, run a remote shell session.

When we examine this connection, we will see that it meets our requirements for a VPN. Data sent, for example, over the public Internet is encrypted and authenticated, ensuring that it is safe from snooping and alteration. From the user's perspective, these VPN functions are transparent. The user need merely call ssh rather than, say, rsh to enjoy the benefits of VPN-like security.

Two versions of SSH are in use today. These are not program versions; they are protocol versions. That is, the SSH protocol has two independent versions. Fortunately, most implementations support both versions and will negotiate which version to use at session start-up time.

In 1995, Helsinki University of Technology researcher Tatu Ylönen developed the first version of SSH. As often happens, he designed it for his own use, in this case, as a response to a password-sniffing attack on his university's network. As also often happens, Ylönen released his code for others to benefit from, and its use exploded all over the world. To deal with the increasing support issues, Ylönen formed SSH Communications Security (SCS, <http://www.ssh.com>) that same year. This version of the software is now known as SSH version 1 (SSHv1).

Actually version 1 of the protocol underwent steady refinement. What is now known as SSHv1 is really version 1.5 of the protocol.

As with SSL, there were no formal design documents for the first version of SSH, but Ylönen did document the protocol after the fact as an Internet Draft (draft-ylonenssh-protocol-00.txt). This draft has long since expired, of course, but is still distributed with the SSH source code and is available in various repositories on the Web (see, for example, <http://www.watersprings.org/pub/id/index-y.html>).

Because of security problems with SSHv1, SCS released version 2 of the protocol in 1996. SSHv2 is a complete rewrite of the SSH protocol and is incompatible with SSHv1. The IETF became involved by forming the Secure Shell working group (SECSH). Their Web site is at <http://www.ietf.org/html.charters/secsh-charter.html>.

In late 1999, in response to increasingly restrictive licenses from SCS, the OpenSSH project (<http://www.openssh.com>) released an SSHv1 implementation based on SCS's 1.2.12 release. This version supported protocol versions 1.3 and 1.5. In June 2000, OpenSSH released support for SSHv2, and support for Secure FTP (SFTP) followed soon afterward in November of that year. At this time, the OpenSSH suite is the most common implementation of the SSH protocols.