One of the easiest and most important things you can do to secure a Linux-based server (other than to change the default SSH port to prevent automated bots from profiling your server in the first place!) is to enforce the usage of SSH keys as an authentication requirement across all of your Linux-based systems. Fortunately, not only is implementing one key for access across all servers pretty easy, but it’s extremely convenient, as well!
Before we get into the details, let’s cover why this is a critical step.
Imagine waking up one morning to find your data encrypted, and an electronic ransom note holding your data — and with it, your business — hostage. Security can unfortunately be an aspect of your business neglected until it’s too late.
Working as the proverbial “the eyes on the ground” at INAP, I tend to see the wider patterns and trends. Frequently, when I log into a managed client’s server to troubleshoot an issue, SSH brute-force attacks are commonly seen due to clientele allowing logins as the “root” user instead of creating a “wheel” or “sudo” user, using the default SSH port (22), and most importantly, not enabling SSH keys as a requirement to authenticate. This, when used in conjunction with an SSH key (passphrase or not) renders the other issues practically moot.
These brute-force attempts can cause a myriad problems — the most important of which include excessive load, as your server will need to handle all the connection attempts, and if successful, scenarios such as data theft or loss, and root level compromises (typically with an associated rootkit dropped to hide any malicious tools and maintain access). These attacks have recently been made more effective by the use of distributed botnets, and modified algorithms to guess common password formats (such as “1-2 words plus 3-7 numbers”). These recent modifications on this long-standing attack vector make these attacks more effective than they have been in the past.
Steps for Setting Up SSH Keys
SSH keys are composed of two parts: a private key and a public key. Through the use of public key cryptography, you’ll use the private key to log in, and the public key as a way for the server to identify your private key.
I do encourage the use of passphrases when possible — otherwise, anyone who has the key has access to your server.
1. Generate a public and private SSH key pair
This can be accomplished on Windows platforms using a tool such as “PuTTYgen,” but I find this is quicker and easier to do on your server as well!
To implement SSH key authorization only on the “root” account, there are 2 methods for cPanel-based servers – By either method if you have cPanel, you’ll see the key appear in WHM should you use it to assist in administration of your server.
- If you’re using a cPanel-based server:
- Log into WHM, and navigate to “Security Center > Manage root’s SSH Keys”
- Click on “Generate a new key”, and fill in the name, passphrase (if desired).
- A secure key type would be RSA, and a good size would be 2048.
- Click “Generate Key”
- Head back to “Security Center” in WHM, and click “SSH Password Authorization Tweak”.
- Verify that your Private key works (see below).
- Hit “Disable Password Auth” to disable password authorization for root (your SSH key’s passphrase will still work of course!).
- If you’re using any Linux-based server, you can also use the command “ssh-keygen”:
- Log into your server as “root” or su to root using your wheel user
- Run the following command for a key using RSA with 2048 bit key strength:
ssh-keygen -t rsa -b 2048 -f (key_name)
(Feel free to read the full manual page here for full usage and options)
The default directory for the root user “/root/.ssh/” is OK, so hit enter. Enter your desired passphrase, if any, and once more for confirmation.
Using the default name, your private key will be stored in “/root/.ssh/id_rsa”.
Grab the private key and keep it safe – “cat /root/.ssh/id_rsa” to copy and paste the key into a local file, or download the key using an SFTP client (then encrypt it!).
2. Verify your SSH keys work.
On all platforms, before disabling password authentication, test your keys using PuTTY or via an SSH tool (On windows machines, we prefer cmdr – it’s an excellent tool).
To log in using cmdr, open the application and run the following command:
ssh user@yourserver -i /location/of/privatekey
- Cleanup and config:
3. Authorize the SSH key.
cat id_rsa.pub >> ~/.ssh/authorized_keys
Should you wish to use this key with multiple servers, download it as well. Put the public key in your other server’s “/user/.ssh/authorized_keys” directory as well, and your Private key will be valid for that user – in this way, you can use one key combination for many servers and/or users. Combined with proper security in keeping the Private key safe, this is a powerful, secure (and convenient!) way of administering multiple servers.
Then, feel free to delete your “id_rsa” file you’ve just downloaded (this is the key you’ll be using to authenticate – so it’s a bit more secure to keep it hidden well!). I highly encourage the use of an encrypted USB drive to manage your SSH keys–especially if you don’t plan to use a passphrase.
Be sure not to delete the “.pub” file until imported into “/root/.ssh/authorized_keys” of course.
This will be your method of root-level authentication to the server from now on, so be sure to keep it in a safe place.
4. Disable password based authentication for “root.”
For any Linux-based server, edit your SSH config file (/etc/ssh/sshd_config) by using “vi/vim”, or “nano.” Change these directives to these values to allow all other users to use passwords to authenticate except root:
PasswordAuthentication yes
PermitRootLogin without-password
That’s it! You’ve now significantly increased your server’s resiliency to automated brute-force attacks. Be sure to keep your key secured; I keep my SSH keys on an encrypted USB drive on my keyring right alongside my car keys. They’re equally important tools.
