To kick start a new life into this blog, I have decided to venture into the realm of SSH security. Going through the troubles I’ve experienced so far in securing my own SSH server, providing tips along the way. This first part is going to probably be one of the more boring parts (read: pre-planning ideas).
The first thing to cover, here, though, is you should highly think ahead of time what security you want, exactly. There’s a lot of rave about key-based authentication, instead of using passwords. While I’ve used both, there’s only one real difference I’ve noticed in switching to using keys (certificates) instead of passwords: logging in is faster. Granted, my testing environment is home-based, so it isn’t exactly the best to base security off of (I have no wireless router, for one). However, using password authentication would generally take me about 5-10 seconds to log in from connecting to seeing my bash shell. While using keys, I’ve noticed it takes about 3-5 seconds, at most, to go from connecting to bash shell.
Another issue on this matter is how secure do you want to be. As I said, I’ve set this up for myself to just learn how to break things so I can fix them again, there is no wireless router, and I’m about the only one who uses the Internet unless my girlfriend comes over, so there’s really no security warnings I should take heed of. However, in a data center, for example, it’s better safe than sorry to keep things as secure as possible without breaking everything. So, for my environment, I would be fine with using passwords (which I was doing for a long time), but in a production environment, it’s wiser to use keys. Not just because of the “do it for security”, but the reason why it’s more secure. While SSH does encrypt the data stream, having a double-layer of security is preferred, so that if someone does get your keyphrase, they don’t have instant access to your server. Which brings me to my next point…
For the sake of preventing bad things from happening, create a dummy SSH account (preferably using /bin/rbash [restrictive bash] for it’s shell). Yes, you should still set a password for the account (since sudo will still be accessible).
Fact is, your system will more than likely become under attack, especially with the more services you run/offer. The reason for creating a dummy SSH account is to basically set up a honey pot of sorts. Do you want a stranger to just walk inside your home, even if you leave a key in a secret spot? I’d think not. The same philosophy applies here. Let the stranger in at the porch door (dummy account), but not at the door letting them into your home (root/some other account). When I set my account up, I ran this:
useradd -s /bin/rbash -d /home/[account] -m -G [ssh only group] [account]
-s assigns a shell to the user (/bin/rbash), -d says where the user’s home directory is, -m creates the home directory, -G adds the user to a group (or list of groups), and “[account]” is the username.
From here, you’ll also want to assign a password to the account. NOTE: Only do this if you’re not root, otherwise just do passwd [account] instead of these two lines.
For my last piece of advice (which will most likely be a two-parter for part 1) here, and this kind of goes into another part as well that’ll be covered in more detail later, create a SSH-only group. I created one called “sshdude”, and assigned my dummy account to that group only. Basically the purpose of this, as I said that’ll be shown in more detail later, will restrict the SSH server from accepting log ins from any account outside of that group. Of course you can specify more groups too, but I only have one group set up.
All in all, this is all more system-based preparation. I know I didn’t go into detail here either about how to set up key-based authentication, but that will come in part 2. The reason being is that this is kind of something that has to set up after you have followed everything else here (well, first you need to make sure you even want to do this method). It’s pretty simple to set up, but can be a bit tedious if you don’t automate the task.
Come to think of it, I might just come up with a script to automate this entire process…but, that’s for another time.