…running Centos 6.2
After seeing a great little tutorial courtesy of @hak5darren I decided to implement this on my VPS box to provide a little extra security while removing the need for private keys.
Granted I can still use private keys at home but it’d be nice to have access to my box when I maybe don’t have access to my private key or using it via an internet cafe.
Step One: Make sure your time is set correctly
Everything we will end up doing is to set up a time sensitive token. If your server is not running on the same time as your mobile phone/authenticator then you’re going to find yourself unable to log into your machine.
In OpenVZ you are unable to use NTP to sync up time or manage timeservers and so you’re stuck to what your physical host is using. Providing your provider is decent enough and is ensuring his physical hosts are kept up to date you shouldn’t have a problem.
If you follow these next steps and your time is still out of sync, you’ve got a problem that I can’t solve. Contact your provider and get him to sort out NTP on his physical hosts.
As you can’t use NTP yourself to set the time, you have to set the correct “offset”. You do this by:
rm /etc/localtime && ln -s /usr/share/zoneinfo/Europe/London /etc/localtime && date
Make sure you set the timezone appropriately for your area. The output should be in sync with your local time now.
Step Two: Get hold of the Google Authenticator PAM
The Pluggable Authentication Module (PAM for short) is available from: http://google-authenticator.googlecode.com
wget and extract the source tarball:
Ensure you have the development tools installed: sudo yum groupinstall “Development Tools”
Ensure you have the pam development libraries installed: sudo yum install pam-devel
sudo make install
With no errors you should now have two files contained within /lib64/security and /usr/local/bin
Step Three: Lets start configuring it
First the system authentication…
Copy the following line into your /etc/pam.d/sshd configuration file.
You can add the above to the system-auth file if you wish but expect problems if you’re running X. I only have a single service I want to protect so I’ve added it as per Darren’s instructions to the service’s configuration file.
Note that each stack (auth, account, session, etc…) is executed in line order. So if you place the above line after the line within the auth stack that deals with “password”, it’ll request a password first, if you place it above the password line, it’ll request a verification code first.
Any references to “include” means that it defers that point of the stack to another file under /etc/pam.d/ so if you want to fine tune where the google authenticator module is called, you’ll need to follow the stack.
Once you’ve added the above line edit your /etc/ssh/sshd_config file to make use of challenge_response authentication.
Ensure “usepam” is set to yes
Ensure “ChallengeResponse Authentication” is set to yes – This is the “Something I have” factor
Enable Password Authentication – This would be the second “something I know” factor.
Another thing to note is make sure that your login grace time is set to something sufficiently large enough for you to type in both the authenticator code and your password. I had mine set to 10s to allow me to type in a keyphrase for my private key, but kept finding my login timing out after submitting a verification code but before I could finish typing my password when using 2FA.
With all the above done you’re now ready for step 4.
Step 4: Configuring your user account
As your normal user enter the following command:
The following exchange will take place. Answers are down to your preferences except for where I’ve marked it in bold.
[[email protected] libpam-google-authenticator-1.0]$ google-authenticator
Do you want authentication tokens to be time-based (y/n) y
Do you want to disallow multiple uses of the same authentication token?
Your new secret key is: AAAAAAAAAAAAAAAAAAAAAA
Your verification code is 111111111111111111111
Your emergency scratch codes are:
Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
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)
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)
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)
Navigate to the URL given to you within the output.
Using the Google Authenticator app on your phone, add an account and select “scan barcode”
Position camera to view the QR code presented to you at the above URL
The Google Authenticator Application will automatically add an account with a value which will update every 30 seconds or so.
MAKE SURE YOU COPY ALL OF THE INFORMATION ABOVE RELATING TO SCRATCH CODES AND SECRET KEYS – IF YOU LOSE YOUR AUTHENTICATOR, YOU WILL BE ROYALLY SHAFTED WITHOUT THESE. Especially if it is your only method of authentication to your server.
Now restart your sshd server using:
And before you log out of your current session. Open up a secondary putty window and attempt to login using your google verification code and a password (obviously having set one for your user).
Step Five: …now you’re auth’n with google
Providing the last step worked, you’re all sorted. Google authenticator is working for you.
Otherwise, undo the above changes and give up as I have no idea what went wrong and if you logout you’ll likely lock yourself out of your machine.