This week I will show you how to set up cryptographic authentication.
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.
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:
Symmetric Encryption | 80 | 112 | 128 | 192 | 256 |
Elliptic Curve Encryption | 160 | 224 | 256 | 384 | 521 |
RSA Encryption | 1,024 | 2,048 | 3,074 | 7,680 | 15,380 |
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
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.
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
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.
Try running commands like this to verify that you are authenticating with keys:
$ ssh -v server1 uptime
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.