SSH (Secure Shell)

Version 0.1

by Peter Schwenk



Introduction

SSH is a suite of programs (ssh, scp and others) that replace the common rsh/xrsh/rlogin/rcp UNIX utilities. They are functionally equivalent, but they use public-key cryptography schemes to enhance the security of authentication and session data transmission. SSH also provides secure X Windows session forwarding so that the xrsh utility is no longer needed. This document will give a brief overview on for what SSH is used and provide pointers to more detailed information on the command-line applications found on UNIX systems and the Windows client sold by SSH Communications Security.

Terms

There are a couple terms that will be used during the course of this document that will be defined here.

Local - refers to the computer initiating a communication session. For example, the computer from which you log into another is called local.

Remote - refers to the target computer, the one into which one logs. For example, the local computer logs into the remote one.

Overview

SSH comes in two versions, 1 and 2, and each uses a different protocol. SSH2 was written to utilize SSH1 when communicating with another SSH1-only computer, so the versions do not matter much. The only problem would occur when SSH1 tries to initiate a connection with a computer that only has SSH2 installed; it would not work. The campus Composer (copland, strauss, mahler, etc.) computers still only run SSH1, so usage of the older version will be briefly discussed.

The Mathematical Sciences Department has both versions installed on all of its Sun and Silicon Graphics (now SGI) computers. The department is also licensed to use the SSH Windows client from SSH Communications Security. All the public host keys are managed centrally, so there should not be any issues with unknown key warnings. Host keys are explained later.

There is a question regarding whether SSH is really worth the trouble when communicating among the department's computers. Everyone's home directories are stored on a central file server, so whenever someone works with files in their home directory, the contents of the files are transmitted across the network unencrypted. Therefore the encryption benefit of SSH is mostly nullified (except with regard to passwords) when used to communicate among our department's computers. The one advantage of SSH that makes up for this downside is automatic X session forwarding. There is no need to fumble with the DISPLAY environment variable and the xhosts access control utility when running X Windows programs on another computer. Also, SSH is indespensible when communicating with computers outside of our department's network, including the classoom network. For example, a Window SSH client can be used to securely communicate with a departmental workstation from a home computer via a dial-up connection. The Windows client also forwards X sessions through an encrypted channel, so Windows computers can securely work with X programs with the appropriate X server software, like Exceed. These reasons alone make SSH worth the trouble of learning and using.

SSH is actually several programs. ssh replaces the old rsh and rlogin programs, and has the same syntax (with many extensions relating to the encryption features). ssh is better than rsh because it supports stronger forms of authentication. rsh relies on passwords (which are tranmitted over the network in clear text and are easily intercepted) or IP (internet protocol) address (which are easily spoofed (a computer sends out network packets that appear to be coming from another, trusted host) ). Besides passwords and .rhosts file authentication, ssh supports two additional forms of authentication: host key based and user key based.

The nitty-gritty of public key cryptography will not be discussed here. There is plenty of information on the subject on the Web. Each computer has a key pair, a private one and a public one. For user key based authentication, the user also has a key pair. Information encrypted with the public key can only be decrypted with the private one (not even the public one can do it). Information encrypted with the private key can only be decrypted with the public one (not even the private one can do it). The public key is able to be advertised, but the private one must remain a secret.

In addition to using the .shosts file (analogous to the .rhosts file used by rsh) to specify computer names (IP addresses) and user names to allow logins, host key based authentication makes sure the host keys match. Both ends of a SSH session, local and remote, must know about each others public keys, which requires a bit of extra work beforehand. If the keys do not match, the user is warned and can elect to abort the connection. The computers host keys are also used to encrypt the communications between machines. Additional security enhancements of SSH was also written to detect the spoofing of IP addresses and contains other safeguards.

User key based authentication ups the security ante by requiring that the user keys match on both ends of the session in addition to the host keys matching. Since the individual user is responsible for her own keys being installed on both ends of the communication, there is greater assurance that she is who she says she is.

Additional Information

To read more about the details of SSH and its use, here are some resources:

Conclusions

It is recommended that SSH be used for all logins both to and from departmental computers and the composers whenever possible. Even with the shortcomings of our particular environment, the protection of your password and the convenience of automatic X session forwarding are reason enough to use SSH. It seems that on a daily basis we are warned of new threats to our personal information. Any measures we can take to protect ourselves are well worth the effort.