ssh: Secure Shell

The ssh program suite is an interesting way to establish a secure communication channel between hosts across the Internet. It replaces a few usual communication channels (such as telnet, rlogin, rsh and rcp) and provides equivalent functionality via a new secure protocol. This article is meant to introduce the user to ssh features without any pretense of being an authoritative tutorial on security issues.

First of all, as usual with encryption material, let's throw in some legalese. The Unix implementation of the package is distributed free of charge for non-commercial use and can be retrieved from major ftp sites around the world. The meaning of “non-commercial use” is well stated in the COPYING file within the ssh distribution. Non-commercial use includes use of the tool by people who work on the Internet, provided ssh is not used as a selling argument. However, being allowed by the license is not enough to use the package. You must also ensure your government allows using cryptographic material: some countries prohibit citizens from using any type of cryptography.

As far as standardization is concerned, the IETF (Internet Engineering Task Force) is working on the ssh idea. This means that the protocol is going to be standardized and will always remain throughly documented. Anyone can reimplement the software and distribute her version with different copying policies. Although there is no RFC about ssh yet, three Internet drafts are already available which document the different aspects of the protocol. The drafts I downloaded in June are going to expire on September 1, 1997, but new drafts (or a real Request For Comments) will be released before that time.

The main aim of ssh is overcoming the security problems of TELNET and rsh-like protocols. These protocols, though widely used, are very weak as far as security is concerned: TELNET transmits clear-text passwords over the network, while rsh and friends are easily broken by spoofing techniques (skilled system administrators or anyone with physical access to the wire can exploit the .rhosts files to be granted access on remote computers). These vulnerabilities are addressed by the ssh protocol by enforcing a strong authentication scheme between the communicating parties.

The protocol not only authenticates the client host with the server, but also enforces encryption of all the data sent through the established communication channel. Although encryption requires some computational load in the communicating hosts, the user can be confident that no sniffer can make sense out of network packets, and nobody can forge packets to be granted access with the server.

Finally, the protocol is designed to allow encapsulation of other communication channels within an ssh stream, so that non-encrypted protocols can benefit from ssh capabilities at no cost. This feature is most useful for establishing secure X11 connections, but its use is much more flexible than just that security.

As far as the user interface is concerned, the new programs are designed as drop-in replacements for rsh, rlogin and rcp. While the system administrator needs to deal with the ssh issue at least to install the package, the final user can happily ignore the fact that the underlying communication mechanisms have been changed.

The current version of ssh, as I'm writing this article, is 1.2.20. It is distributed with a configure script, so that:

 ./configure && make && make install

does the complete job of installing the package. Even if /usr/local belongs to you, you'll need to be a privileged user in order to install ssh. This requirement is necessary, because both the server and some client programs must be able to open privileged TCP ports. Moreover, the package installs its system-wide files in the /etc directory. If you must run an ssh session without installing the programs as a privileged user, you should first read the FAQ file, which describes how to accomplish this without too much trouble.

The program suite is made up of a server program, a few clients and a pair of support tools. In order to become an ssh server, the suggested action is to invoke sshd from your initialization files when the computer boots. The program is installed by default in the /usr/local/sbin directory, and it listens to port 22/tcp of the local host to accept incoming connections. You should add a line like the following one to the /etc/services file, if it is not already included:

ssh     22/tcp  # secure shell

It is possible to run sshd from /etc/inetd.conf, by passing the -i flag to the daemon. This practice is discouraged, because the daemon can take several seconds to start, as it generates an encryption key each time it starts.

On the client side, nothing needs to be done at installation time to enable use of the services. After installation, several programs can be found in the /usr/local/bin directory that can be executed by anyone. Here's a list of these programs:

Although the number of installed files might scare a novice user, there's nothing new to learn as long as you just use the plain ssh and scp client programs. The system administrator can even choose to replace ssh for rsh and scp for rcp, so that secure operation is completely transparent to the final user. Actually, such a replacement is not completely transparent, since ssh introduces a new feature not present in plain rsh or rlogin: X11 forwarding. This feature is considered a “side effect”of using the ssh protocol and is described in the next section.

The role of the other programs is secondary. They help to set up a good working environment to avoid typing too many passwords during normal operation without compromising system security. While knowing their internals is not essential for program operation, a quick look over the documentation might provide interesting insights about current encryption technology and can help in configuring hosts to automate the login process.