Passwords are so 2001, and quickly become a major pain in the neck when you’re routinely shelling into Linux servers to do stuff. As a rule, I set up publickey authentication whenever I’ll be working with a server, and there seem to be so few human-friendly articles on what it is, and how it works. So here’s mine!
What is “Public Key Encryption”?
There’s a long, complex answer that stretches back to the dawn of computing, cryptography and impressive neckbeards. The short answer is, it’s a way of securing information in such a way that anyone can lock a file, but only one person can unlock it.
You’ll always have two keys: A public key, and a private key. The public key can be placed anywhere – in email signatures, on web pages, billboards – and the private key has to remain private. To make this a bit more accessible, think of the public key as a padlock, and the private key as an actual key:
One key, one lock, simple. You put that lock on something you want to secure, and then you use the key to open it – this box, for instance:
So now, you need to provide your private key in order to unlock the box. Where public key encryption comes in useful, is that you can copy the lock (public key) as many times as you want, and use it to lock whatever you want:
And now you can use the same private key to unlock all of those. There’s a lot more to asymmetrical encryption, but the off-hand, casually derogatory mention of neckbeards has already filtered that audience out, so we move on:
Public Key Authentication for SSH
When you connect to a server, the first thing it does (after all the other things) is tell you what authentication mechanisms it supports. There are loads, but two common ones are “password” and “publickey”.
Right now, you’re not using public keys, so your client prompts you for your password, and you get logged in:
But, to extend our analogy, we can set up public key authentication – so instead of a password, you use your private key to unlock the session:
Best part is, you can have this happen entirely automatically – so to connect to a server, all you have to do is:
And you’re connected and authenticated without any further intervention on your part. We’ll do this by putting a public key on the server, and telling the SSH system to offer it you as a login method.
Setting it up
To set that up, there are 3 things you need:
- A server that supports publickey authentication – which is a default, and if it’s disabled on your server, there are more serious questions you should be asking your administrator.
- An account on the remote server – which I take for granted you already have
- A public/private key pair on your local machine.
We’ll start by generating a key pair. If you’re on Windows, you’ll use PuTTYgen for this (which requires an article all on its own, and won’t be covered here), and if you’re on a *nix OS like OSX or any Linux variant, you’ll simply do:
ssh-keygen -t dsa
And hit enter for every prompt that comes up. By pressing enter through everything, it will create a pair of files in a special folder, and it won’t lock the key with a passphrase.
(The fact that I even used the phrase, “lock the key” should indicate that there’s more to this than this cursory breeze through the subject of encryption, so do your own homework if you have questions.)
Take a look at them like so:
That should list 2 files – possibly more, if you’ve been using the system a while:
The first one is your private key – under no circumstances should this key be shared, ever. The second is the public key – our padlock, which we’ll be uploading to the server like so:
scp id_dsa.pub remoteserver:~/
What does that mean?
- scp – Secure CoPy, which can move files over SSH connections
- id_dsa.pub – The file we’re copying
- remoteserver – The hostname of the target, and:
- :~/ – on the target (:), copy it to the user home directory (~/)
When that’s done, connect to the server like normal:
If it’s never been run before, run ssh-keygen here, too – it creates the folder structure which we’ll need, in order to do:
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
That reads the content of the file and appends it to authorized_keys, which is what the SSH server reads from when accepting incoming keys. The second command deletes the file (since we no longer need it).
Now, exit, and try shelling in again. If everything works out, you’ll be dropped straight into an authenticated shell session, no passwords necessary.