shared key ssh authentication

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:

Obviously, your username & hostname are probably going to be different, as is the generated fingerprint. This creates two files, ~/.ssh/id_rsa and ~/.ssh/ 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:

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 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.

Case study:

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.


8 thoughts on “shared key ssh authentication”

  1. This works fine when your local and remote username are the same, but how do you use/generate a key pair when your local and remote usernames are different?

    My local Machine is called David_Desktop, my local user is david@David_Desktop

    The server I want to log into is called WWW1, and my account on that machine is DaveAdmin@WWW1

    I can work with password authentication just fine, but I want to set up a CVS/SVN repository on WWW1 and don’t particularly want to enter my password fifteen times every time I want to do a commit.

  2. Scratch that…. the problem wasn’t with the key pair, it was with my spelling.

    Seriously, who spells Authorised with a ‘z’????

    As a minor aside, once the public key was catted into Authorized_Keys “ssh DaveAdmin@WWW1” works fine, but “ssh WWW1” still doesn’t work.

  3. The problem you’re having with trying to ssh w/o specifying the username is simply because your local and remote usernames are different.

    There’s really no secure way for it to know that david@localhost is really DaveAdmin@www1.

    As far as SVN goes, it can remember usernames for you – and should by default, even when using svn+ssh.

    I generally recommend against using svn+ssh if at all possible. If you need encryption, svn over https is equivalent and is generally more reliable.

  4. The other problem that you didn’t identify in your Warning Section, is the obvious one where in your example you allowed ROOT login from a remote machine. That is one of the First Basic Security steps that should be done.

  5. Of course you’re right, allowing any sort of remote login directly to the root account is the sort of thing you need to consider very carefully. I would never recommend allowing direct login as root from the public internet.

    In is particular case, I was the only one ever using the box and only ever from another host on the same switch. I also required the RSA authentication – there was no password, login was only possible via the key so I don’t feel bad about it.

    Also if I actually need to plead my defense further, this did happen about 7-8 years ago when I was substantially less experienced 😉

Leave a Reply

Your email address will not be published. Required fields are marked *