A Brief Intro to SSH

This document is intended to give a brief overview and quickstart to ssh in the context of IU CSci.

What it does

SSH stands for "secure shell", but this is really a misnomer; its name resulted from an analogy to "rsh", the remote shell provided by Berkeley Unix tools. SSH is a tool for secure connections between networked machines; it provides secure authentication without having to send passwords in the clear. SSH can be configured to simply encrypt password transfer, to use public key authentication, set up secure channels, do port forwarding. It can also provide authentication using PGP, Kerberos, and X.509 certificates - with (currently) some strong caveats.

It does not provide authorization, except in a very limited and kludgy way. SSH provides security for the connection between machines, but if a host is subverted then you have no protection. The commonly used SSH applications are

SSH, Kerberos, and Globus

The advantage of SSH is that a user can run it on machines without root privilege or the need for a CA (certificate authority). It is easy to set up and deploy, and so is widely available - last estimates from March 2001 were that 3 million hosts are running SSH daemons. The disadvantage is that the user has to handle key distribution. By contrast, using X.509 certificate based mechanisms require a CA, but the user need not transfer keys explicitly to machines and configure the remote host account to accept them. SSH solutions are not scalable to large numbers of machines, while X.509 certificate methods are.

Kerberos provides both authentication and authorization. Furthermore it provides some security even when a host is subverted - only if the KDC (key distribution center) machine is violated will your accounts be permanently seized. A penetrator into a Kerberos workstation can steal your tickets but they expire after a finite time, and unless you do something dumb like store your passwords on the machine, the hacker's access ends with the ticket. Not much consolation if an "rm -r *" was done on your account, but with backups that is recoverable. Furthermore, Kerberos-based applications like DCE give sophisticated ACL (access control list) capabilities to users - which SSH does not. On the other hand, Kerberos takes major effort, planning, and maintenance to use and essentially cannot be done by a non-root user. At IU, you can have your workstation join the local DCE cell, but it requires that your machine be "blessed" by a UITS person.

Versions and protocols

People say "ssh" but the term refers to the protocol, the ssh application, and various implementations of the protocol. I will follow tradition and use the term in a confusing way. There are two major protocol versions: I'll concentrate on using SSH2 protocol. Along with protocol versions, there are three major implementation families of SSH: Right now it is a toss-up between OpenSSH and SSH2; the only sure thing is to avoid SSH1. Features of OpenSSH: Most of the machines at IU are running ssh2; however, as of this writing the IBM SP/2 farm is running OpenSSh.

Using ssh (in the IU CS Department)

Most of this is designed from a user's point of view. If you are installing ssh2 as a root, then likely you are doing so on a Linux system. My recommendation is to configure with --withlibwrap, which lets you use inetd filtering tools. Beyond that, the defaults are mostly OK.

Your first step is to run ssh-keygen to set up your public and private keys. But wait! A confusing problem right now is that we still have at least remnants of ssh1, ssh2, and openssh utilities on departmental CS machines (and more generally, all over campus). So when you run ssh-keygen, you need to beware of which one you really are running. Do a "ls -l" on the command. If it is a link to something like /usr/local/bin/ssh-keygen2 then you are using the right one; if it is a plain executable or script then likely you are using ssh-keygen version 1. Generally,

If after running the key generation a directory $(HOME)/.ssh is created, then you used ssh1 or openssh. If .ssh2 was created, you ran ssh2. Below I'll only deal with the .ssh2 case.

When you run ssh-keygen you will be asked for a passphrase. Use a long one, and make it unguessable. When using ssh-agent (more later) you only have to enter it once, when first logging in on your local workstation, so the extra typing is worthwhile. You can have a comment attached to the key by using the -c option, which will help you remember the passphrase later. This is crucial since God himself cannot retrieve your passphrase if you forget it (not even Rob Henderson can retrieve it - and that's who God goes to when he forgets his passwords).

Inside of the .ssh2 directory there will be three files: id_dsa_1024_a : a private key id_dsa_1024_a.pub : a public key random_seed : just ignore this. More generally the naming scheme is id_KEYTYPE_KEYLEN_X, where KEYTYPE is the PKI method, KEYLEN is its length in bits, and X is the key pair sequence letter (run ssh-keygen2 again and it will be b, then c, etc.) As usual with public key infrastructure, the public key needs to be widely distributed, while the private one should be unreadable by anyone. If you are paranoid, you can specify that the .ssh2 directory gets created in a no-backup directory. If you are superparanoid, you will create it on a floppy and carry it with you, never copying it to a hard drive. And you will use a keylength of 8192.

At this point, you can do "ssh whale" to do a secure login. Unless you were doing all of the above on whale, you will be asked for your ssh passphrase, that will fail, and then you will be asked for your whale password. That is, first RSA authentication was tried, and then ssh falls back to password authentication. Although the password goes across encrypted, you will want to be able to use the RSA methods - and that means distributing your (public) keys to other machines. Here is my recommended procedure:

  1. on each machine where you want to login or copy files, follow the above procedure to create the .ssh2 directory and files. (actually, you can use the same keys on each machine) Suppose those machines are m1, m2, ....
  2. on machine mk, copy the id_dsa_1024_a.pub file to a file named mk.pub.
  3. copy each mk.pub file to every one of your .ssh2 directories on all the other machines (it is left as an exercise for you to come up with how to do this with the minimal number of copy operations!). You can use scp to do this copying securely; the syntax from machine mk to machine mj is scp mk.pub mj:.ssh2/mk.pub
  4. create a file called authorization, containing the lines 
    Key                 m1.pub
Key                 m2.pub
...                 ...
  5. on each machine, create the file identification containing the line 
    IdKey id_dsa_1024_a

At this point you can ssh from any machine mk to another machine mj, and have authentication via public key. You will be asked each first time that the host is new, and if the hostkey should be accepted and saved; say yes.

ssh-agent

All of the above is not of much help, unless you use an agent that supplies your keys - this which in turn means you can The latter also includes forwarding of all your graphics windows, etc.

Using it is simple: when you start up Xwindows, instead of a command like "startx", do "ssh-agent startx". Or in a window, do "eval `ssh-agent`". Just running "ssh-agent" in a window will not work! This is because ssh-agent needs to set some environment variables which must carry over to any child processes that you want to do ssh from. Then do "ssh-add", and enter your local passphrase. Afterwards, whenever you do "ssh mk", the agent will supply your passphrase for you, and have remote Xwindows automatically forwarded back to you. If it doesn't, see the notes about common bugs below.

SSH2 and OpenSSH

OpenSSH is more like ssh1 in the way it handles keys. If you need to interoperate between ssh2 (like IU CS runs) and OpenSSH (such as that used on the IU SP/2 run by UITS), you can use ssh-agent by converting your ssh2 public key to an OpenSSH one:

More Stuff

There is a good tutorial from Berkeley about ssh, with links to most of the distributions. O'Reilly and Associates have a book SSH, The Secure Shell: The Definitive Guide, although it is the nature of the protocol that books get quickly outdated.