APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed
February 2005
© February 2005 Tony Lawrence

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.


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

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.

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.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> SSH passphrases and keys


Inexpensive and informative Apple related e-books:

Take Control of Apple Mail, Third Edition

Take Control of Pages

Take Control of Numbers

Take Control of Preview

iOS 8: A Take Control Crash Course

More Articles by © Tony Lawrence

Tue Feb 15 21:43:36 2005: 29   wsandersatwsandersdotnet

Older (real old) versions of SSH and the "commercial" (F-secure, etc) SSHs will not do publickey authentication if the account password (/etc/shadow) is locked or expired, of if the password hash isn't 13 chars long.

To work around this set the account password to something valid but very hard to guess (like "shb8db3k").

Tue Feb 15 22:47:46 2005: 30   TonyLawrence


Thank you - that's good to know.

Tue Jul 26 11:16:39 2005: 871   anonymous

I have this error when I run a file that has a commmand : ssh (hostname). Could you help me?? Thanks a lot
WARNING: RSA key found for host redhat02.dvm.ript.edu.vn
in /root/.ssh/known_hosts:4
RSA key fingerprint 77:17:52:fe:62:48:f7:1b:83:cd:e0:70:83:4b:45:d3.
The authenticity of host 'redhat02.dvm.ript.edu.vn (' can't be established,
but keys of different type are already known for this host.
DSA key fingerprint is f5:dd:b5:6c:3d:b4:7b:a0:9c:df:d2:40:bd:34:9a:c0.
Are you sure you want to continue connecting (yes/no)?
Host key verification failed.

Tue Jul 26 11:42:44 2005: 872   TonyLawrence

Remove the entry at line 4 of /root/.ssh/known_hosts

Mon Feb 25 14:17:14 2008: 3702   anonymous

AllowUsers secretuser othersecretuser@192.168.3.*

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

pedantic mode, but you indicated 192.168.3 which is not 192.168.2

Mon Feb 25 14:22:26 2008: 3703   TonyLawrence

Thanks :-)

Fri Jul 31 13:01:59 2009: 6712   dpl

Hi, thanks for the article. About that empty passphrase: Is the name of the server I
connect to with that key stored in the files? If not, an adversary would have to guess
(or extract from my other files) the corresponding server first, so there would be
some security left?

Fri Jul 31 14:18:59 2009: 6713   TonyLawrence

The fear here is someone getting on to your local machine and from there getting to the other because of the empty passphrase.


Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

One day my daughter came in, looked over my shoulder at some Perl 4 code, and said, "What is that, swearing?" (Larry Wall)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode