SSH supports a number of different methods of authenticating connections. The two most common are password and shared key (and I’m not going to talk about the others, since they’re for rather specific applications). By default, and in almost every case where people use SSH, they’re probably entering a password. This is generally good for security, but bad for convenience, scripting, and a number of other things.
When setting up shared keys between two accounts, there is only really one big decision to be made – do you want to require a password or not? If you do so, that password is independant of either the source or destination accounts’ passwords. If you don’t set a password on the key, you effectively merge the two accounts into one – making transitions between them very transparent in deed.
I tend not to set passwords on my ssh keys. This means that I can scp files between machines without having to type the password every time, which in turn means that I can run backup scripts over an encrypted connection or use gvim to edit a remote file securely without having to tunnel an entire X session. There are lots of uses.
But I digress. You just want to set it up, eh?
Suppose I am setting up passwordless stuff between two servers, Bender and Fry. The basic procedure for creating my key pair looks like this:
ammon@bender:~$ <b>ssh-keygen -t rsa</b>
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ammon/.ssh/id_rsa): <b>[enter]</b>
Enter passphrase (empty for no passphrase): <b>[enter]</b>
Enter same passphrase again: <b>[enter]</b>
Your identification has been saved in /home/ammon/.ssh/id_rsa.
Your public key has been saved in /home/ammon/.ssh/id_rsa.pub.
The key fingerprint is:
Obviously, your username & hostname are probably going to be different, as is the generated fingerprint. This creates two files, ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. These are your private and public keys (respectively). And, because you didn’t type in a password when creating them, they’re not going to ask you for a password when you want to use them.
In addition to creating an RSA key, you could also create a DSA key, but RSA keys work with both SSH1 and SSH2 (not that you’re using SSH1, right?). For our application, there’s no real reason to choose one over the other.
Now that we have our keys, you need to send the public key to the other server. The SSH daemon looks for public keys of friendly accounts in ~/.ssh/authorized_keys, so the process is probably going to be something like this:
ammon@bender:~$ <b>scp .ssh/id_rsa.pub fry:.ssh/authorized_keys</b>
ammon@fry's password: <b>[password]</b>
id_rsa.pub 100% 996 1.0KB/s 00:00
Now, if the universe is right, when I try to ssh over to Fry, I won’t be prompted for a password. To make things happy the other way around (to allow Fry to log in to Bender w/o a password), you just repeat the process the other way around. That is, create a key pair on Fry, copy the public key over to Bender.
If we were to add another server (Zoidberg) to the list, you’d repeat the process by creating a keypair over there and copying the public key to both Fry and Bender, and making sure Zoidberg’s authorized_keys file contains a copy of both Fry’s and Bender’s public keys. The more machines you add to the mix, the easier it is to forget to update one.
I find it helpful to make a copy of the public key in the form hostname.pub when generating a new key and copy it everywhere. Then, on the remote machines I execute a cat *.pub > authorized_keys to regenerate the index.
And, just because I am such a good citizen, I figure I’ll close out with a warning. Be careful with this, if one machine in your little family of key-sharing happiness is compromised, the rest are. Also, it is healthy to keep track of which accounts can talk to which other accounts in order to track down/make changes in the future.
At a previous job of mine, I had set up passwordless shared key ssh into the root account of one of the (non-mission critical) servers from my desktop, since that was the only place I was logging in from, and I was doing it a lot.
Well, 9 months after I quit, I typoed an ssh command – and wound up with root privs on the box. My brief examination of the machine showed that while the guy who replaced me was bright enough to change the root password itself when I left, he didn’t check for ssh keys. I discovered three other accounts that were similarly accessible by keys created by users who were no longer with the organization.