SSH passphrases and keys

We've discussed ssh security in several articles here. This article takes the ideas in Security Paranoia - restricting ssh access a step farther. To understand all of this does require some background, so bear with us: it won't be hard, and it will increase your security.

Keys

In Security Paranoia - restricting ssh access, we talked about restricting ssh logins to a particular user or set of users. We also locked out accounts after a small number of incorrect passwords. This increases our security, but we can take it quite a bit farther if we don't mind giving up a little convenience.

As we left it, we have a specific user or users allowed ssh access. You have to know that user name and password to login, but you can do so from anywhere in the world with no prior arrangements. That's convenient: it lets you use any ssh client on any machine. For example, I can be at a client and ssh back to my home machine. If we assume that I'm not worried about a fake ssh client that is going to steal my passwords (though that's certainly possible), and I have the "lock after bad attempts" set up, this is fairly safe.

But it can be much more secure. The first step for that is to understand public keys and passphrases. I talked about those a bit in SSH Basics, but will go over it briefly here again.

ssh-keygen

You start by generating key files:

ssh-keygen -t dsa
# this is for Openssh

You'll be asked for a passphrase. It's possible to just hit enter twice and have no passphrase, but you'll see shortly why that's not a good idea except in special circumstances. You'll also be asked for a file name; the defaults are probably what you want if you've never created keys before (however, if you HAVE created keys, you'd want to give a different name - more later).

You then need to put the public key (.ssh/id_dsa.pub by default) into the authorized_keys2 file on the server. Once that's done, if you attempt an ssh to the server, you'll be asked for your passphrase rather than the password of the user on the server.

Here's the most important thing to understand at this point: The password at the server doesn't matter anymore. You could log into the server and change the password, and ssh is still going to let you in because of the public key and the passphrase you've provided. You could even edit (as root, of course) /etc/shadow on the server and put a "*" in the password field, which would mean that no password could EVER be used to login as that user, but you could still login as that user using ssh and your key files/passphrase.

Here's the second thing: those keyfiles are transportable. You could take them to any other machine in the world and use them to access the server. All you need is the files and your passphrase, and THAT is why you wouldn't want to use an empty passphrase: if your key files were stolen and have an empty passphrase, that's all anyone needs to access your server - well, there is more we can do about that, but for what we've done so far, that's the case. If someone took your files to another machine, they could just do

ssh -i yourstolenid_dsa yourlogin@yourserver

If the passphrase were blank, that's it: they are in. But if you did use a passphrase, they need it - more security.

So, what do we have now? With a little less convenience, I can still access my server from anywhere. I just have to bring my id_dsa and id_dsa.pub files with me. But I had to replace the password field with a "*" in /etc/shadow, which means I can't even login at the console as that user. That might be fine: in my case, I only use that user for remote access, and no other users are listed in /etc/ssh/sshd_config's AllowUser lists. The inability to login except by ssh keys is no hardship. But it's not the only way to control this. In sshd_config, you can specify

PasswordAuthentication no
PubkeyAuthentication yes
# don't forget to "kill -1 `cat /var/run/sshd.pid`"

That says that the ONLY way you can ssh in is with a acceptable public key. If you have a password you can still use it, but NOT for ssh. With this line, ordinary passwords can not be used for ssh logins. In my case, I have that in place AND a "*" in the password field: there's nothing wrong in securing yourself from multiple angles.

If you don't need to login from random locations, you can specify allowed hosts:

AllowUsers secretuser othersecretuser@192.168.3.*

The "secretuser" can ssh from anywhere, but "othersecretuser" has to come from a 192.168.3 address.

Forget the expense of flying to New England. Forget hotel and meals costs.
Installation and light training Boston and New England

Multiple Identities

You CAN just use one set of keys and put the pub key information in authorized_keys2 on every server you need to access. If you put in the safeguards discussed here, and only carry your passphrase in your head, you are pretty secure. But if you DO travel around with your keys, it is at least possible that someone COULD trap you with a trojan horse ssh client that steals your keys and your passphrase. If you only use the one set, you've given away access to everything. For that reason, you may want to generate separate keys for different servers.

More interesting is that keys don't necessarily have to give full access. You may have a full access key that you use within your office, but another key that you use while traveling that gives you less complete access to your server. We'll talk about some of the possibilities there in a future article.

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here