GNU/Linux is a fantastically secure Operating System (given many of the alternatives). However, like any security measure, it is only as strong as the humans operating and administering it. What use is the world’s strongest lock on your front door if you leave a window open? Alternatively, what good is locking the door if the lock can be thwarted by sliding a credit card through it?
Before getting into security, please view the Ubuntu Server Guide (PDF). You’ll also want to review Ubuntu’s Security wiki article. This is going to be a long one, so here we go.
One of the many responsibilities of being a System Administrator with A Small Orange’s Operations team is to keep up with security issues. Because of this, I go to a lot of security conferences (“hacker cons“)- where exploits new, old, and clandestine are revealed to like-minded individuals. Many (most, if not all) of these individuals are not there to gain information on how to break into systems, but rather are security professionals interested in learning what attacks are in the wild in order to protect themselves against them (even FBI and other law enforcement agents attend these conventions to learn and share their knowledge!). You also learn some neat things in hacking “real life”- for instance, thanks to friends at TOOOL I know how to pick locks. It’s SUPER handy for when you lock your keys inside your car or house (and, admittedly, it happens to me a lot). Many of the people presenting are “pentesters“. It’s assumed and expected that any and all knowledge you gain from these conventions is to be used for good and not evil. For an analogy, if you know how cars work you can either fix them for people or you can sabotage them. Sabotaging people’s cars is generally frowned upon by mechanics and engineers.
Now with that aside, let’s talk about what this article sets out to do and what it does not set out to do.
This article aims to:
What this article does NOT set out to do:
Got it? Great! Let’s move on to the juicy details.
Passwords are a series of (hopefully) random characters that make up a complex sequence. Passphrases are a combination of words that make up that sequence. It is generally considered that long passphrases are more secure than passwords, but that is still being debated. It’s safe to assume that for most attacks (both bruteforce and dictionary attacks), however, a passphrase of seven words or longer that doesn’t resemble normal speech patterns is sufficient.
Generally, A Small Orange will never need your password/passphrase. There may be fringe cases where we request it (notably if it regards a particular web application e.g. WordPress) to troubleshoot, but for 95%+ cases we won’t need it. Be sure to follow this advice when using your passwords/passphrases, and this article has a lot of information on how to choose strong passwords (I personally use pwgen– typically with the command
pwgen -sy 26 1 – to create randomized strong passwords).
Hey, remember when I told y’all about how you can use SSH to connect to your server’s terminal? Well, now we’re going to focus on how to lock down SSH even more. Using a strong password is good, but not even giving an attacker the chance to bruteforce or dictionary attack your password is even better!
SSH supports public key authorization, or “pubkey auth” (Ubuntu article). This means that if you lock SSH down to only authorized keys, you can disable password logins- thus effectively thwarting both bruteforce AND dictionary attacks. A Small Orange staff has keys installed by default on new servers so we can gain access to your servers without needing to reboot them- typically, if you need to reset your root password or the like. Ubuntu has specific details on setting this up server-side, starting with how to edit and apply SSH settings.
First, we need to get pubkey authentication working.
ssh-keygen -t rsa -b 4096#Note: you can just hit enter for each of the questions asked to accept the defaults. It is recommended that you set a password for your key.
cat ~/.ssh/id_rsa.pub#Note: be sure that you cat id_rsa.pub and not id_rsa. The .pub file is your public key, which can be safely redistributed. The file without the .pub at the end is your private key, and that should never leave your computer or be seen by others.
mkdir -p /root/.ssh ; chmod 700 /root/.ssh
ssh-copy-id -i ~/.ssh/id_rsa root@YOUR-SERVER-IPbut this may fail (I can’t recall offhand if Mac OS X has ssh-copy-id). If it fails, follow the instructions below. If it succeeds, you can skip them.
scp ~/.ssh/id_rsa.pub root@YOUR-SERVER-IP:/root/mykey
cat /root/mykey >> /root/.ssh/authorized_keys ; chmod 600 /root/.ssh/authorized_keys ; rm /root/mykey
Again, Windows requires some different steps made possible via the PuTTY suite. See my original SSH article for installation instructions; make sure you install the installer.exe version as this will include all tools we need.
And you’re done! Now, close your connection (type
exit to exit the server shell if you’re logged in) and attempt to SSH in again. It should ask you for your key password, if you set one. If not, it shouldn’t ask for a password at all. Have no fear, this is expected and normal behaviour- it means the server authenticated your server based on the key you’re using and thus didn’t need you to put your server’s root password in.
Now, what was the point of all that? Technically, we’re only half finished.
Stay tuned for the conclusion tomorrow!
Existing Customers get 50% off 1st hosting invoice
w/ Coupon OJ2013
Good for all new hosting plans & upgrades.