HOWTO: set up ssh keys

Paul Keck, 2001

    Getting Started

  1. First, install OpenSSH on two UNIX machines, hurly and burly. This works best using DSA keys and SSH2 by default as far as I can tell. All the other HOWTOs I've seen seem to deal with RSA keys and SSH1, and the instructions not surprisingly fail to work with SSH2.
  2. On each machine type ssh somemachine.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper perms.
  3. On your primary machine where you want your secret keys to live (let's say hurly), type

    ssh-keygen -t dsa
    This will prompt you for a secret passphrase. If this is your primary identity key, make sure to use a good passphrase. If this works right you will get two files called id_dsa and id_dsa.pub in your .ssh dir. Note: it is possible to just press the enter key when prompted for a passphrase, which will make a key with no passphrase. This is a Bad Idea ™ for an identity key, so don't do it! See below for uses of keys without passphrases.
  4. scp ~/.ssh/id_dsa.pub burly:.ssh/authorized_keys2
    Copy the id_dsa.pub file to the other host's .ssh dir with the name authorized_keys2.
  5. Now burly is ready to accept your ssh key. How to tell it which keys to use? The ssh-add command will do it. For a test, type

    ssh-agent sh -c 'ssh-add < /dev/null && bash'
    This will start the ssh-agent, add your default identity(prompting you for your passphrase), and spawn a bash shell. From this new shell you should be able to:
  6. ssh burly
    This should let you in without typing a password or passphrase. Hooray! You can ssh and scp all you want from this bash shell and not have to type any password or passphrase.

Using X Windows

Now this is all well and good, but who wants to run their whole life from a single bash instance? If you use an X window system, you can type your passphrase once when you fire up X and all subprocesses will have your keys stored.

  1. In the ~/.xinitrc file, modify your line which spawns windowmaker to read:

    exec ssh-agent sh -c 'ssh-add </dev/null && exec /usr/local/bin/wmaker'
    This will prompt you for your passphrase when you start up X, and then not again. All shells you spawn from X will have your keys stored.
  2. This brings up a security issue- if someone comes upon your X session, they can spawn ssh sessions to burly and other hosts where you have put your id_dsa.pub information into the authorized_keys2 file. A locking screensaver like xlock is vital.

Different usernames

By default ssh assumes the same username on the remote machine. If you have a different username on the other machine, follow the normal ssh procedure:

[pkeck@hurly /]$ ssh -l paulkeck burly

More keys!

You are not limited to one public key in your authorized_keys2 file. Append as many as you like! If you, say, generated a unique private key on every machine you log into, and then appended the id_dsa.pub files to each of the other machines' authorized_keys2 file, you'd have the equivalent of a .rhosts file with two added benefits: This command will do it without requiring an scp and vi session:

cat foo.pub |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'

Single-purpose keys

So now you're sshing and scping your brains out. Sooner or later you'll come across one or both of these situations:
  1. You want to automate some ssh/scp process to be done after hours, but can't because no one will be around to type the passphrase.
  2. You want to allow an account to do some sort of ssh/scp operation on another machine, but are hesitant to append a key to your authorized_keys2 file because that essentially "opens the barn door" to anything that other account wants to do, not just the one operation you want to let it do. (This is the situation if you use a .shosts file.)
Single-purpose keys to the rescue!
  1. Make yourself another key:

    ssh-keygen -t dsa -f ~/.ssh/whoisit

    Just press return when it asks you to assign it a passphrase- this will make a key with no passphrase required. If this works right you will get two files called whoisit and whoisit.pub in your .ssh dir.

  2. cp ~/.ssh/whoisit.pub tempfile

    We want to work on it a little. tempfile should consist of one really long line that looks kind of like this:

    ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== pkeck@hurly.example.com
    
  3. Edit tempfile and prepend some things to that line so that it looks like this:
    command="echo I\'m `/usr/ucb/whoami` on `/usr/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
    
    That will do what we want on Solaris; to try this example on Linux use this:
    command="echo I\'m `/usr/bin/whoami` on `/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
    

    The stuff to prepend is your command that will be run when this key is activated, and some options to keep it from being abused (hopefully). The last thing on the line is just a comment, but you probably want to set it to something meaningful.

    Also, most examples I see use no-pty as an additional option, but this messes up the carriage-return/linefeediness of the output of the above example. (Try it.) I haven't looked into it enough to see why you would want it, but there you go.

  4. cat tempfile |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'

    Append tempfile to your authorized_keys2 file on burly.

  5. To "activate" (or perhaps "detonate") the key from hurly (or anywhere that has the secret key), do this (maybe there is a better way?):
    ssh -i ~/.ssh/whoisit burly

    The following also works but is cumbersome:
    ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && ssh burly'

    You can also append this "command key" to a different account's authorized_keys2 file and trigger it from a different username. You just need the secret key. Like so:
    ssh -i ~/.ssh/whoisit -l paulkeck burly'

    The next leap in the pattern is something like this:
    ssh -i /home/pkeck/.ssh/whoisit -l paulkeck burly'

    This could be run by any user on the box if they could read your secret key, so always keep your .ssh dir and all your keys chmodded to 700 and 600 respectively.

  6. You could make single-purpose keys with commands to (haven't tested all these):

    You can send the stuff on STDIN with something like this on the triggering machine:
    ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && cat alarm.au | ssh burly'

    or

    ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && tar cf - /home/pkeck | ssh burly'

    Maybe for that one the corresponding command to "catch" that stream would be:

    cat - > ~/backups/pkeck.tar.`date +%Y%m%d.%H-%M-%S`

    You get the idea! Go crazy!

    Tape examples from Ed Cashin's Gettin' Fancy with SSH Keys, my inspiration for getting into this whole thing!

[an error occurred while processing this directive]