HOWTO: set up ssh keys

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:

• Someone would need to know your passphrase to use it, so a cracker gaining access to an account on one machine will not jeopardize the other accounts. (If you foolishly use the same passphrase or, heaven forbid, id_dsa file on all the hosts, it would make it easier to exploit, so don’t do that.)
• Traffic is encrypted.

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/whoisitJust 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 tempfileWe 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 burlyThe 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):
   • mt -f /dev/nst0 rewind
     Rewind a tape on a remote machine
   • nice -n 19 dd of=/dev/nst0
     Send STDIN to that tape drive. Maybe STDIN is a tar stream from tar -cf -.
   • nice -n 19 dd if=/dev/nst0
     Read stuff from there to my STDIN
   • cat claxon.au > /dev/audio
     Play an alarm noise on a remote machine
   • cat - > /dev/audio
     Play any sound you send on STDIN
   • cat - > /etc/dhcpd.conf
     Replace /etc/dhcpd.conf with some stuff from STDIN on the triggering machine (sounds like a temp file would be better)

   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`

Ref: HOWTO: set up ssh keys