APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds RSS Feeds











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> SSH passphrases and keys


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 (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 [email protected]*
 

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

(Article continues after the break)



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.




If this page was useful to you, please help others find it:  





8 comments




More Articles by - Find me on Google+



Click here to add your comments
- no registration needed!




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

gravatar


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 (192.168.49.160)' 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

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







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


AllowUsers secretuser [email protected]*

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

gravatar
Thanks :-)



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

gravatar
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

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

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

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

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

pavatar.jpg

This post tagged:

       - SSH
       - Security















My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide



Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)