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 to ssh features without any pretense to be an authoritative tutorial on security issues.

Bureaucracy

First of all, as usual with crypto material, let's throw some legalese in. The Unix implementation of the package is ditributed free of charge for non-commercial use, and can be retrieved by major ftp sites around the world. The meaning of "non-commercial use" is well stated in the COPYYING file within the distribution of ssh. Non-commercial use includes use of the tool by people who work on the internet, provided ssh itself is not used as a selling argument by anyone. But being allowed by the licence is not enough to use the package: you must also ensure your government allows using cryptographic material: some countries just prohibit its citizens from using any cryptography. As far as standardization is concerned, the IETF (Internet Engineering Task Force) is working on the ssh idea. This means the protocol is going to be standardized and will always remain throughly documented. This means, among other things, that anyone can reimplement the software and distribute his/her version with different copying policies. Although there is no RFC about ssh yet, three Internet Drafts are already there to document the different aspects of the protocol. The drafts I dowloaded in June are going to expire on September 1st 1997, but new drafts (or real Request For Comments) will be released before then.

The problem

Overview of the package

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 all the 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 applies 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 /etc. If you really need to run an ssh session without installing the programs as a privileged user, you should read the FAQ file, which describes how this can be accomplished without too much trouble. The program suite is made up of a server program and a few clients, as well as a pair of support tools. In order to become an ssh server, the suggested action is invoking sshd from your initialization files when the computer boots. The program is installed by default in /usr/local/sbin, and it listens to port 22/tcp of the local host to accept incoming connections. It is suggested to add a line like the following one to /etc/services, if your file doesn't carry one:

ssh     22/tcp      # secure shell

• ssh (slogin) The ssh client program behaves like rsh: it executes a command on a remote host, redirecting to the remote command its own stdin, stdout and stderr. If only one argument is specified in the command line, it is taken as the remote host, and ssh opens a terminal session on that host, like rlogin does. The slogin client is therefore just a symbolic link to ssh. Usually, the user is asked to provide a password to authenticate herself on the remote host.
• scp As you might imagine, "Secure CoPy" is a replacement for "Remote CoPy". It uses the same syntax and performs the same task, with the same security enhancments offered by ssh. The user is usually prompted for a password to perform autenthication.
• ssh-keygen The program generates new keys associated to the user invoking ssh-keygen. The public key and the private key thus generated are saved by default in the directory $HOME/.ssh/, in two files called identity and identity.pub. A pair of keys is needed if you want to securely log in the local host from outside without providing a password.
• ssh-agent The agent is a program meant to manage security for a user session. It keeps hold of private keys for the user and can be contacted by any child process. See the man page for more information about the agent.
• ssh-add The program adds identities to the authentication agent. ssh-agent must be an ancestor of the process running ssh-add in order for them to communicate.
• ssh-askpass This short program is used internally by ssh-add and ssh-keygen to ask for a passphrase using the X graphical environment.
• make-ssh-known-hosts The perl script retrieves the public keys of all hosts in a domain: it queries the DNS and talks with hosts belonging to a domain. This program updates /etc/ssh_known_hosts to hold the new keys. The program should be run periodically, usually via cron, to reflect any change in host public keys or new installations of ssh on hosts in the local networks.

X11 forwarding

The ssh protocol is designed to be flexible, and supports multiplexing of several communication channels within a single TCP stream. This choice results in two effects: on one side the implementation of the protocol is much more elaborate than other TCP-based protocols, on the other side the final user can exploit the added flexibility to achieve new goals. One of these goals is establishing secure communication channels between the X server and client applications: the feature is enabled by default whenever an ssh session is established. The idea behind X11 forwarding is quite straightforward: the ssh application runs locally and is able to connect to the local X server without resorting to the network (via local Unix-Domain Sockets); remote graphic programs, on the other hand, can connect locally to the sshd server which spawned the remote shell (via the loopback network interface); the remote sshd, finally, can encapsulate graphic data in the secure communication channel it owns, to complete the path linking the graphic application and the X server.

Figure 1 shows how a remote X application (running on sandra) securily connects to the local X server (on morgana).
ssh.ps

When you log in a remote computer through ssh, the DISPLAY environment variable is automatically set to a proper value, and no user intervention is needed to establish the graphical channel. The following screen-shot shows automatic assignment of DISPLAY:

morgana% ssh sandra env | grep DISPLAY
DISPLAY=sandra.systemy.it:10.0

Authentication

The main problem when establishing a connection through an insecure network is performing reliable authentication. The ssh package is quite pedantic about autenthication, and you'll be prompted for your password more frequently than usual. Typing passwords over and over is distressing, and can be avoided by proper configuration of system files. Note also that any password you type is transmitted after establishing the encrypted communication channel. You can try ssh -v (verbose) to be reported what is happening; the information returned is very useful if you are being prompted for a password and you didn't expect to. But let's look at the steps performed by ssh to authenticate a user in the remote server. First, if the target account has no password, access is granted. If this doesn't apply, different kinds of authentication engines are tried; each of them can be enabled or disabled in the server. For example, by default ``PasswordAuthentication'' and ``RhostsRSAAuthentication'' are enabled, and ``RhostsAuthentication'' is disabled. The following is the sequence of actions when you try to log in a server running with the default configuration -- which can be changed in /etc/sshd_config.

• The client receives the public key of the server. If it is unknown, ssh asks interactively to the user if the connection must be continued. By confirming, the user trusts that the remote host matches its name, and the public key of the server is saved on the client, in $HOME/.ssh/known_hosts. This step is not performed if the server hosts is known system-wide (it appears in /etc/ssh_known_hosts).
• The client tries authenticating through ``RhostsRSA''. This requires that ``Rhosts'' authentication succeeds: either .rhosts in the user's home directory or /etc/hosts.equiv allow login. sshd is more pedantic than rlogind in checking these files, and denies permission if any of the files are group-writable or world-writable. Needless to say, the ``plus'' entry in either file is disregarded. Moreover, .rhosts is not even used if the home directory of the user is group-writable or world-writable, and /etc/hosts.equiv is not used to authorize root logins. In addition to the standard files, sshd also checks .shosts in the home directory of the user and /etc/shosts.equiv. These files are useful if you still want to run rshd or rlogind on the server hosts by trusting less hosts than you trust via ssh.
• If the previous step succeeds, RSA is tried (Random-State Authentication). This technique consists in the client sending a challenge to the server, which must correctly reply: the challenge consists in random data encrypted using the client's private key; the server must decrypt such data and return its checksum. The server can only solve the challenge if it knows the public key of the client, which is only known if the remote user agreed to trust the client (local) host. RSA is used to prevent authorizing untrusted hosts which forge DNS records or which temporarily stale the IP address of a trusted host.
• If either of the previous steps fails, i.e., if ``RhostsRSA Authentiation'' as a whole fails, the client reverts to ``Password Authentication'', by asking a password to the local user.

Alghorithms and future directions.

The design of ssh is full of hooks for future extensibility. First of all, the client and the server exchange a ``software version'' and a ``protocol version'' at the beginning of each section. While the ``software version'' is mainly used in debugging problems, the ``protocol version'' is a great resource to accomplish smooth upgrading from one version of the software to the next one. Both the client and the server are required to support at least the previous version of the protocol, in addition to the current one.

This requirement is designed to help dealing with the transition period whenever the protocol gets enhanced (which doesn't happen too often, anyways). You can try to run ``ssh -v'' to see, among other things, the exchange of version strings. Another great design feature of the protocol is that new cryptographic algorithms (``ciphers'') can be added to the basic machinery without loosing generality. This is accomplished by choosing which cipher to use only at run-time. During handshake (the first few packets being exchanged by the communicating parties) the server declares which cyphers it supports and the client chooses one of those ciphers.

Every ssh implementation is required to support at least ``3DES'', in order to ensure a secure link can be established between any client and any server. Users and/or organization are nonetheless free to implement new ciphers and specify them as the default choice. A few ciphers are part of the official ssh distribution, and the user can ask for a specific algorithm on the ssh command line to override the default. The protocol also supports compression of session data, and a compressed session can actually be faster than a non-compressed one, if the local network is slightly loaded. Once again, complression is optional, and the communicating parties agree whether to use it or not. The standardization efforts endorsed by the IETF are aiming at defining version 2.0 of the secure shell protocol (the version supported by ssh-1.2.20 is called 1.5). The ``internet-drafts'' currently available document three different aspects of the upcoming 2.0 protocol:
the connection protocol (draft-ietf-secsh-connect-00.txt),
the transport-layer protocol (draft-ietf-secsh-transport-00.txt)
and the authentication protocol (draft-ietf-secsh-userauth-00.txt).
These documents are quite technical, but very interesting to look at. The protocol the IETF is working on looks very promising, and even more flexible than the current one. The curious reader is urged to browse the network to retrieve more information about these topics. I can provide a few pointers to begin with, but I'm pretty sure you'll find several more pointers about this kind of topic.

The ssh home page is at http://www.cs.hut.fi/ssh

The Unix version of the software is mirrored throughout the world, and it originates from ftp://ftp.cs.hut.fi/pub/ssh

Commercial implementations of the package are distributed by DataFellows: http://www.datafellows.com

The designer of ssh has founded his own company, whose entry point is http://www.ssh.fi

The ssh faq is at http://www.uni-karlsruhe.de/~ig25/ssh-faq/

As far as cryptography is concerned, a good starting point for net surfing is http://www.cs.hut.fi/crypto

The IETF is at http://www.ietf.org/, and the group dealing with ssh standardization is at http://www.ietf.org/html.charters/secsh-charter.html

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved

Reprinted with permission of Linux Journal