You’ve made the choice to use CentOS 7 in your data center or even on-premises. With it up and running smoothly, you of course want to ensure that it is locked down tight. The last thing you need is for that server to suffer intrusion or data loss. One thing you can do to dramatically lessen the likelihood of your CentOS server being hacked is to setup two-factor authentication (2FA).
I’ve already covered how this is done on Ubuntu, but the installation process for CentOS is slightly different. Let’s get this up and running.
What you’ll need: Obviously you’ll need CentOS 7 up and running. You’ll also need a user account with sudo rights capable of logging into the server via ssh. You’ll also need an authenticator app (such as Authy or the Google Authenticator). And that’s all you need.
This is where the process slightly varies from Ubuntu. With CentOS 7, you must first install a repository before you can install the necessary tool. The repository in question is epel and can be installed with the following command:
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Once the repository is installed, you can then installed the google-authenticator with the command:
sudo yum install google-authenticator
Once the software is installed, you’re ready to proceed.
Using the google-authenticator
The google-authenticator command must be run by any user who will be logging in, via ssh. As a standard user, issue the command:
You will be first asked: Do you want authentication tokens to be time-based (y/n) y. Answer yes to that and you’ll be presented with a QR code. Scan that code with either the Authy or Google Authenticator app, so you can add that account to your two-factor authentication app on your mobile device. You will also want to copy and save the emergency codes you are presented.
With that out of the way, answer with the default to the following questions:
- Do you want me to update your “~/.google_authenticator” file? (y/n) y
- Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y
- By default, tokens are good for 30 seconds. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n
- If the computer that you are logging into isn’t hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y
Again, every user that needs to log into the CentOS server, via SSH, must do the above.
There are two files you must edit. Open the first with the command sudo nano /etc/pam.d/sshd. At the bottom of this file, add the following:
auth required pam_google_authenticator.so
There is an option to add nullok at the end of that line. This is an option if you have users who have yet to run the google-authenticator command and need to log into the server, via ssh. I prefer to not use that option and make sure everyone has run the command before configuring SSH to require 2FA.
Save and close that file.
The next file is opened for editing with the command sudo nano /etc/ssh/sshd_config. Look for the line:
Change the above line to:
Save and close that file.
Restart sshd with the command sudo systemctl restart sshd. At this point, anyone that attempts to log into the CentOS server, via SSH, will have to include a verification code from either the Authy or Google Authenticator app. Without a code, they cannot log in. Period. If you find 2FA not working, you might have to restart the server. Make sure you have physical access to the server in case something goes wrong so that you can log in locally and troubleshoot.
A must do
Every CentOS (or Linux) administrator should consider this a must do for servers. Even though SSH is a very secure protocol, locking it down even further can go a very long way to ensure the safety of your servers and your data.