There are never enough questions about Linux server security and how to be sure that no one, except you, would ever be able to connect to it. We've discussed this before with our articles on using key-based authentication and Fail2ban. I can personally think that you should always use keys to access SSH on your server, because even the best passwords can be broken. Not to mention having to change it every few months and trying to remember it. Yeah, I know password managers exist but when we're talking about your server with sensitive data on it, you want to be damn sure it’s safe. And that’s where 2-factor authentication comes in.
Back in the day, it was something like in the movies: two people entering theirs unique passwords and pressing buttons simultaneously to open the secret hangar or something. Now it’s just entering a quick, temporarily generated, password you recieved in a text to confirm it's really you using your password. But enough analogies. Let me show you how to configure your CentOS server to use Google Authenticator's 2-factor authentication service. Make sure you get the relevant Android or iPhone apps before using it.
Install required packages and make sure you have the current time set on your server:
yum install make gcc pam-devel ntp chkconfig ntp on service ntpd start
Add EPEL repository and install the Google-authenticator package:
yum install epel-release yum install google-authenticator
Configure your Google authenticator. You'll also need to answer some questions. We provided a simple guide to the answers for you, too.
[root@serversuit ~]# google-authenticator https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@centos-512mb-fra1-01%3Fsecret%3DENFNPPXC3VPT5ZEV Your new secret key is: ENFNPPXC3VPT5ZEV Your verification code is 282506 Your emergency scratch codes are: 44365444 68651888 65307512 43469780 11074666 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 and 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 1:30min to about 4min. 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
Edit ‘/etc/pam.d/sshd’ file and add the line shown below at the top of the file:
auth required pam_google_authenticator.so nullok
The ‘nullok’ directive means that Google Authenticator will be applied only for users that have ‘~/.google_authenticator’ file in their profile.
Configure ‘sshd’ service
Edit ‘/etc/ssh/sshd_config’ file, check the settings below and restart the service:
PasswordAuthentication yes ChallengeResponseAuthentication yes UsePAM yes service sshd restart
Now it’s about the time to test your settings:
login as: root Using keyboard-interactive authentication. Verification code: Using keyboard-interactive authentication. Password: Last login: Thu Jun 2 08:29:20 2016 from [root@serversuit ~]#
If you enter the wrong verification code you should see the following error in the ‘/var/log/secure’ file:
Jun 2 08:38:06 serversuit sshd(pam_google_authenticator): Invalid verification code
So, as you can see, even if your password becomes compromised would-be intruders still can’t login to your server without your smartphone!
Just some advice, before I let you go:
1. Hold on to your secret key and emergency scratch codes. You’ll need them if you reset, or lose, your smartphone.
2. You can allow login to your server from local network without using 2-factor authentication: just create a file ‘/etc/security/access-local.conf’ with the following content and you're good to go:
# Allow access from the local network’s + : ALL : 10.0.0.0/8 + : ALL : 172.16.0.0/12 + : ALL : 192.168.0.0/16 + : ALL : LOCAL - : ALL : ALL
I used the usual local networks, so you'll need to figure out which ones will work for you.
3. If you are logging with SSH keys then you won't be asked for your verification code! It make sense, since SSH key authentication is already strong enough. But you should still use 2-factor authentication without key file if you're working from untrusted environment.
That's all for now. I hope that this article will help you out! Follow us on Twitter and Facebook, to stay updated with future articles.
Until next time!