HOWTO: set up ssh keys

Paul Keck, 2001

Getting Started

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.

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.

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.

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.

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:

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.

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

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.

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:

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.

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!

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.

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

Edit tempfile and prepend some things to that line so that
it looks like this:

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.

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

Append tempfile to your authorized_keys2
file on burly.

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.

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'