Two-Factor authentication for SSH in CentOS 6 using Google Authenticator
Category: Cloud Servers  
The security of your server is strongly reliant on establishing the identity of your users at login time. This is something that the username and password combination should achieve. Unfortunately, the majority of users have a tendency to neglect security in favour of ease. It’s common for users to do things like re-use passwords in various places. So, if their password is compromised somewhere else, the password they use to access their account on your server could be vulnerable, too.
A solution to help with that is to use two-factor authentication to access the server. This means that when logging in they will be prompted for another authentication method beyond just a password. In this article we will look at setting up Google authenticator as an authentication method in CentOS 6.
Google Authenticator implements the systems as described in the Internet Engineering Task Force’s Request For Comments 6238, which describes how to create a secure time-based one-time password system.
What this means in the real world is a system which relies on the server and client generating a pass code based on a shared secret key and the current time. The code will change every 30 seconds, meaning that, should someone write down one of your codes, they’d not have a chance of using it before the code expired.
Anyone can create their own implementation of the system and they are all inter-compatible so while we will use Google Authenticator on the server, you can use any RFC6238 compatible client software to authenticate with. The client software is normally installed on a mobile phone.
Now lets look at installing it. Unfortunately it doesn’t come in the main repositories and is part of the EPEL extended repositories, so if you’ve not enabled them already, you’ll need to do so by downloading the rpm file to set them up and then install them…
sudo yum install epel-release-6-8.noarch.rpm
Once that is installed you can install Google Authenticator from that repository…
sudo yum install google-authenticator
Now you’ll need to fire up your favourite text editor. I’m using nano in the example, but you can use whichever is your preference. You need to edit the /etc/pam.d/sshd file as so…
sudo nano /etc/pam.d/sshd
And add the following line at the top of the file…
auth required pam_google_authenticator.so
Once done you now need to edit the /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config
Now find the line containing “ChallengeResponseAuthentication” and make sure the uncommented line says…
ChallengeResponseAuthentication yes
Now you can restart the SSH server…
service sshd restart
Now you and your users can configure Google authenticator for use. Each person who will be using it will need to install the application or an equivalent on their smartphone. Google have their apps in the Play store and the Apple app store. There are also plenty of other implementations of the RFC6238 in the various smartphone app stores available for use. Once a user has the relevant smartphone app installed they are ready to set up the server side part of the application. When logged-in as their user they simply need to type the following command to start the process…
google-authenticator
Now it will display the secret key that will need entering on the phone app to create the verification codes. It will also show a handful of emergency codes that can be used to get in if the phone is lost or broken. If you record those then you need to keep them very safe.
Next there will be a few questions to answer regarding how they want to use the service. The first question is simple; do they want to update the ~/.google_authenticator file, pretty simply asking if they want to save the changes, it’s a yes.
Secondly, comes ‘do you want to allow multiple uses of the same token (validation code)’. This means that you can only use a specific token once, and as each token lasts for 30 seconds it’s going to slow down logging in if the user makes a mistype of their password. Yes and no for this one are a trade off between increased security and convenience.
The next question gives the option of having codes valid for one and a half minutes or four minutes. Unless the time is likely to fluctuate on your server, and if it does it’s probably a good idea to install NTP to keep the clock in sync, then you should be fine with the one and a half minute time window.
The final question asks whether you want to use google authenticator to enable rate limiting of 3 login attempts every 30 seconds. This will significantly slow down brute force attackers trying to break in so it’s worth saying yes to.
Once the last question is answered the system is enabled and you are ready to log-in using the one time passwords. At this point I’d recommend starting a new SSH session to the server to test it rather than logging out, as if the secret key was copied incorrectly or there’s an issue with authenticator you won’t be able to get back in.
Once you are satisfied that things are working properly then you can log out the original session. If there is a problem, you can delete the .google_authenticator file from the user’s home directory and they will be able to log in again with only a password asked for.