Adding Google Authenticator 2-Factor Auth to an OpenVZ VPS

…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 …

…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:

  1. 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:

  1. wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2 && tar jxvf libpam-google-authenticator-1.0-source.tar.bz2
  2. Ensure you have the development tools installed: sudo yum groupinstall “Development Tools”
  3. Ensure you have the pam development libraries installed: sudo yum install pam-devel
  4. cd libpam-google-authenticator-1.0
  5. sudo make install

With no errors you should now have two files contained within /lib64/security and /usr/local/bin

  • pam_google_authenticator.so
  • google-authenticator

Step Three: Lets start configuring it

First the system authentication…

Copy the following line into your /etc/pam.d/sshd configuration file.

  • auth    required                        pam_google_authenticator.so

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:

  • google-authenticator

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

https://www.google.com/chart?BLAHBLAHBLAHBLAH….
Your new secret key is: AAAAAAAAAAAAAAAAAAAAAA
Your verification code is 111111111111111111111
Your emergency scratch codes are:
   111
   222
   333
   444
   555
Do you want me to update your “/home/user/.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)

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:

  • sudo service sshd restart

or

  • sudo /etc/init.d/sshd restart

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.

2fa

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.

Going for the low end…

So I’ve been umming and ahhing for a while about buying a VPS to use for hosting files or playing with the IP over ICMP and DNS tunnelling system, even playing with a basic PBX setup to hook up with my sipgate account that I use for a landline. Bu…

So I’ve been umming and ahhing for a while about buying a VPS to use for hosting files or playing with the IP over ICMP and DNS tunnelling system, even playing with a basic PBX setup to hook up with my sipgate account that I use for a landline.

But 3 things have stopped me from doing it in the past.

1. Security – I’m paranoid, more so now i’m in my current job about just how easy it is to break into systems without too much hassle. Heck I do it for my day job, do I really want to take on board the full management of a server that has no security other than what I apply to it.

2. Security – I’m paranoid but I’d consider myself at least proficient at my job. What’s the likelihood I’ll tweak something, knacker the install and have to rebuild it over and over just because I was trying to lock it down just that bit more.

3. Cost – VPS instances aren’t cheap for something that may be left alone for months before being used on occassion.

So I never got around to it, I did mess about once but after pooching the firewall and having to pay £15 for a server rebuild as they had no other way of accessing it and support wouldn’t just take the firewall down for me I cancelled the account and never looked again.

Until now. I’ve been browsing the entries over at www.lowendbox.com and monitoring the offers up there, understandably a lot of the offers are flashes in a pan, you pay $5 for access to an amazing VM, a week later the company stops trading and starts up another scam.

However I came across a post about a company called “quickpacket” offering a very basic low end VM (128mb ram, 256mb vSwap, 20GB HDD, 500GB transit) for $15 for 12 months.

At just over $1 a month I figured I could suck that up if they disappeared overnight, but I read into them. They’ve been trading quite a while now, looks like a seller of webspace primarily but have moved into VPS hosting.

So yes, I am now the proud new owner of a mini-VPS. Stay tuned for developments but on the cards i’m thinking private svn repository, ICMP Tunnelling and maybe a play about with that PBX idea.

P.S. I’ve already locked myself out of it at least 10 times, thank goodness they have other means to access it and a great big “rebuild” button for when you absolutely hosed the box, no additional costs 🙂