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
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.
You start by generating key files (this is done on the machine you are planning to connect from, not at the machine you are connecting to):
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 (the machine you want to connect to). 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.
(You can store the phrase using ssh-agent. This eliminates having to type it constantly. See SSH Basics)
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
# 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
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
AllowUsers secretuser email@example.com.*
The "secretuser" can ssh from anywhere, but "othersecretuser" has to come from a 192.168.3 address.
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
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
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2011-04-23 Tony Lawrence