Set Up SSH Keys For Easier And More Secure Authentication

This week I will show you how to set up cryptographic authentication.

Two Benefits at Once!

Security and convenience are usually at odds, an increase in one usually has the collateral damage of driving the other one down. But cryptographic authentication is a rare opportunity to make things both more secure and easier to use. Learning Tree’s Linux server administration course teaches you how to administer an enterprise-class server, you need to add this technique to administer several of them.

Here’s how to set things up.

Generate the Key Pairs

You will use the ssh-keygen program to generate key pairs. For the greatest interoperability, generate pairs for all of the latest asymmetric ciphers: the classic RSA plus the elliptic curve ciphers ECDSA and Ed25519.

A U.S. NIST/NSA study concluded that these are the key lengths in bits for approximately equal resistance to brute-force attacks:

Ed25519 keys have a fixed 256-bit length, thought to provide security equivalent to a 128-bit symmetric key (overview here, details here).

ECDSA keys can be 256, 384, or 521 bits long (yes, 521 and not 512), the last believed to be equivalent to a 256-bit symmetric key or a 15,380-bit RSA key (details here).

RSA keys currently default to 2048 bits, but you can ask for longer ones.

To set things up cautiously, first, think up a pass phrase. Not a pass word, but a pass phrase. Something you can remember, and type accurately when you can’t see what you’re typing, and most importantly, something very unlikely for someone else to guess.

Now run these three commands:

$ ssh-keygen -t ec25569
$ ssh-keygen -t ecdsa -b 521
$ ssh-keygen -t rsa -b 4096

If you have to support backward-compatibility to less secure systems, like GoDaddy’s SSH service as I described last week, also create a (fixed-length) DSA key pair:

$ ssh-keygen -t dsa

Agree to the default locations for key storage, and carefully type that pass phrase twice for each key when asked. The result will be something like this:

$ ls -la ~/.ssh
drwxr-x---    2 you  you   1024 today .
drwxr-x---  132 you  you  15872 today ..
-rw-------    1 you  you    736 today id_dsa
-rw-r--r--    1 you  you    613 today id_dsa.pub
-rw-------    1 you  you    444 today id_ecdsa
-rw-r--r--    1 you  you    277 today id_ecdsa.pub
-rw-------    1 you  you    464 today id_ed25519
-rw-r--r--    1 you  you    105 today id_ed25519.pub
-rw-------    1 you  you   3247 today id_rsa
-rw-r--r--    1 you  you    754 today id_rsa.pub

Check Your Permissions!

Permissions are critical! The public key files (named *.pub) should be mode 644, the private key files (without .pub) should be mode 600. The .ssh directory itself should be at most liberal mode 755, or mode 750 or even 700. If the group write bit is on for the directory, or either group or world read for any private key file, authentication will fail with no obvious explanation.

Authorize Yourself Cryptographically

Now create a file authorized_keys containing the public keys for the identity allowed to authenticate in:

$ cd ~/.ssh
$ cat *.pub >> authorized_keys
$ ls -la
drwxr-x---    2 you  you   1024 today .
drwxr-x---  132 you  you  15872 today ..
-rw-r--r--    1 you  you   1749 today authorized_keys
-rw-------    1 you  you    736 today id_dsa
-rw-r--r--    1 you  you    613 today id_dsa.pub
-rw-------    1 you  you    444 today id_ecdsa
-rw-r--r--    1 you  you    277 today id_ecdsa.pub
-rw-------    1 you  you    464 today id_ed25519
-rw-r--r--    1 you  you    105 today id_ed25519.pub
-rw-------    1 you  you   3247 today id_rsa
-rw-r--r--    1 you  you    754 today id_rsa.pub

Distribute Your Keys

Now decide what problem you’re trying to solve. You will need all of these files on the systems you will want to authenticate from. That means the computers in your office and your home, including your laptop. Yes, you might misplace that laptop, that’s why we were careful to store the private keys in a format encrypted with that pass phrase.

Uh-oh. Now you’re worried that your pass phrase isn’t secure enough. If you’re just starting this project, simply regenerate all the key pairs. But if you have already deployed them, use the -p option to ssh-keygen to change the pass phrase for each. See how here.

Now you have your key collection ready to copy? Good. Copy it to another machine:

$ scp -pr .ssh laptop:

The first time you do this, you will be asked for your UNIX-family-style pass word on the remote system. After that, you will be asked for the pass phrase for your SSH keys.

Now you need to put the authorized_keys file on every system you want to authenticate to.

You could create each remote directory (in mode 750 or stricter) and copy the authorized_keys file over. Or just copy your entire ~/.ssh directory with all key files as in that last step. If you’re worried about those private key files, re-think your choice of the pass phrase.

Things Are Now More Secure!

Try running commands like this to verify that you are authenticating with keys:

$ ssh -v server1 uptime

But I’m Still Asked For The Pass Phrase Each Time…

We’re more secure, but I’m out of space for this week. Come back next time to see how to make it simultaneously easier to use with an SSH key agent.