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 [email protected]*
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 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.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
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.
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.