November 28, 2013 · 2fa authenticator debian google hacks linux paranoia raspberrypi security server ssh tricks

Security Paranoia - Google Authenticator For SSH

If you want to secure your Linux machine from attacks you should change the default fort number for services such as SSH, FTP or your web server. While this is a good practice if you're extremely paranoid, there still have to be another ways of doing this. Indeed, there are. There is one in particular I'm really fond of, though this method is not suitable for everyone and every situation, and you should really consider all the pros and cons of using this method. We're talking about securing SSH access with Google Authenticator and creating two-factor authentication method for your machine.

Before we begin

google-authenticatorThere seems to be real ado about this method of authentication nowadays. More and more services, including GitHub, Evernote and others, are incorporating 2FA into their services. This is understandable, especially for companies keeping critical personal data (kind of ironic in the NSA era, to be honest"¦). But what benefits would you gain from incorporating 2FA into your personal space, and should you actually use it?

First of all, what is two-factor authentication? Sometimes shortened to 2FA, it gives you an extra layer of security that requires not only your password and username to access a service, but also a piece of information only you should know and have access to, such as a physical token. While in theory it could even be a security question, it wouldn't be that secure since that kind of information is yet available on the Internet thanks to Facebook and co. Using a username and password combined with a 2FA token makes it harder for potential intruders to gain access and steal your personal data or identity. Google Authenticator is a good example of 2FA, but there are also other methods such as a fob or a USB key.

What are the benefits

First of all, better access control. Implementing the 2FA would give you better knowledge of who is and trying to log into your machine. The other good reason is to remove most of the fake login attempts. A lot of "H4CK3R" wannabes (yeah, I did it on purpose!) use dictionary techniques of merely guessing your password, not really being a real threat to your system. If it takes them more than a few seconds to get in, they'll most likely skip your system because they want to show off their "SKILLS" to their mates. (Yeah! I can hack, look at me! I can hack!). It doesn't discourage everyone but does a nice job keeping kids off the block.

All the handicaps

Well, for use with SSH, there seems to me more disadvantages than good things with implementing 2FA. As you might already know, using 2FA with Gmail or Twitter (you use 2FA, don't you?), accessing your account with additional authentication can be a pain, especially if you use TOR to access the Internet or want to read your mail on public machine. Logging into your account is time consuming in those cases and somehow forces you to use a smartphone, as is the case of Google Authenticator. What if you have a dumbphone? Well, there exist apps that mimic the functionality of GA but I cannot recommend any. Simply because I don't use any. As much as it is painful, most services are created with the assumption you use a smartphone. Tricky.

One of the biggest disadvantages is the fact you can lock yourself out of your account. This can happen especially if you don't have a backup plan (you should have one for your own good), such as backup one-time codes. In the unfortunate event of locking yourself by lack of Google Authenticator (your phone may be lost, stolen, data wiped out) or providing few wrong codes, you might find yourself unable to log into the server and not be able to do your work. GA provides emergency token numbers, so before you decide to use it, remember to obtain them while setting it up.

Now, the biggest harm that 2FA brings with itself, is if someone gains access to your phone or account. If someone gets their hands on your smartphone with GA app installed, you're doomed.

Should I use two-factor authentication?

It really depends on your needs. There is no use installing 2FA on your media centre, laptop or a machine that has no access from the outside of your home network. Ask yourself, would you really care if an intruder logged into your server and found those kitten photos in an unsecured folder? Is my machine holding any compromising data that anyone could benefit on?

Setting up Google Authenticator

Okay, so you still want to set up 2FA on your machine. That's good, I believe you have good reasons to do that and you're not overly paranoid. This set up is being doe on a Debian based system, thus if you're using another distro, make appropriate adjustments along way. I won't teach you how to set up and secure SSH, I assume you've already done that and if not, make sure you can do that. Before we move forward, I have to warn you I take no responsibility for you locking yourself out of your machine. I just give you instructions on how this can be done and won't feel responsible for your personal mishaps. If you decide to set 2FA, you must have some knowledge of the system you're working on.

You should also have already the Google Authenticator app installed on your phone. You can definitely get it for Android, iPhone or Blackberry (go to on your BB). I'm not sure about Windows phones (and am too lazy to google it). Set up instructions are available from Google support.

Preparing your machine

Before the magic can happen, you need to install some additional software. We're be doing it on Raspbian 3.10.18+ #594 PREEMPT Wed Nov 13 17:59:34 GMT 2013.

First of all, update your system if needed:

user@machine ~ $ sudo apt-get update && sudo apt-get upgrade

Now install the necessities:

user@machine ~ $ sudo apt-get install build-essential \ 
make \ 
libpam0g-dev \ 

We need build-essential package as we're going to compile the authenticator from sources. make is used to do the compiling, linking and installing. Since we're dealing with a PAM module, we need to install the development libraries (libpam0g-dev) and, just for safety measures, include the regular library - libpam0g, you never know if it's going to be needed.

After installing the basic components, head to /usr/local/src to get your fingers dirty. We'll download the authenticator package using wget and save it as gauth.tar.bz2, to make our work easier

user@machine /usr/local/src $ sudo wget -O gauth.tar.bz2

Now we'll unpack it:

user@machine /usr/local/src $ sudo tar -xf gauth.tar.bz2 && sudo rm gauth.tar.bz2 
user@machine /usr/local/src $ cd libpam-google-authenticator-1.0/

and start the hard work.

We have to modify the source a bit as we need PAM support. This is why we're using the source code and will be compiling. While inside the authenticator directory, open the Makefile and just before the line

VERSION := 1.0

put the following:


This will tell the compiler to use PAM module while compiling. Now let's do the compiling itself. It's not difficult at all:

user@machine /usr/local/src/libpam-google-authenticator-1.0 $ sudo make

Next, we need to install it into our system:

sudo make install 
cp /lib/arm-linux-gnueabihf/security 
cp google-authenticator /usr/local/bin

Now is a good time to reconsider using Google Authenticator with your SSH, as we're heading towards configuration of the authenticator.

Setting up Google Authenticator

Simply run the google-authenticator program as the user you wish to log in via SSH. You'll be asked a few questions:

user@machine ~ $ google-authenticator 
Do you want authentication tokens to be time-based (y/n)

Time-based tokens are more secure, as they change every 30 seconds, while one-time tokens mean the token doesn't change until it's been used. We'll be using time-based tokens here.

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)

As we've already said, once the token is used, it won't allow you to use it again.

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)

Since we are using time-based tokens it might be beneficial to enable this function, especially if your Internet connection happens to be laggy. If you'd wish to change this in the future, edit ~/.google_authenticator and add line "  WINDOW_SIZE 17, just above "  DISALLOW_REUSE. Next:

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)

It's good to be enabled, especially when you know how tricky and persistent the H4CK3R5 can be.

Now, you've probably noticed by now that we've omitted one part. Before the questions were asked, you got something like this:|0&cht=qr&chl=otpauth://totp/user@machine%3Fsecret%ABCDEFGHIJKLMNOP 
Your new secret key is: ABCDEFGHIJKLMNOP 
Your verification code is 123456 
Your emergency scratch codes are: 

Copy and paste the URL (use the URL created for you by the application, as mine won't work for you) into your browser and scan the QRCode that pops up. If you can't scan the QRCode, enter the information manually with the secret key and verification code provided by your google-authenticator.

NOTICE: Do not neglect the emergency codes! Save them right away in an encrypted file, print them out and** keep them in your wallet, tattoo them onto your pupil, they will save your life once you don't have access to your smartphone.**

Configuring SSH

Next steps are easy and quick to do. First we need to set up PAM for use with SSH. Edit the /etc/pam.d/sshd by adding the following line at the end:

auth required

This ties the Google Authenticator to your account and assures a success authentication only with the use of GA.

Another edit, would be done at /etc/ssh/sshd_config. Locate the line containing:

ChallengeResponseAuthentication no

and change the no to yes. This will enable the use of PAM modules for authentication.

Before restarting SSH, make sure you've set up the Google Authenticator on your phone and have the backup codes. Check once again. Unless you want to risk locking your machine. Once you are 1000% sure, restart SSH:

user@machine ~ $ sudo service ssh restart


Now we can try the Authenticator out. Let's create (if you don't have one) a test account that doesn't have Google Authenticator set up with:

user@machine ~ $ sudo useradd tester 
user@machine ~ $ sudo passwd tester

Try logging in with that account onto your machine:

user@machine ~ $ ssh tester@localhost

From machine the GA is installed on, or

user@anothermachine ~ $ ssh tester@machine.ip

from another computer. You probably noticed, that if you typed in the user's password, it just bounced back wanting for the password again. That's because of the line we added to the /etc/pam.d/sshd file.

Now, try logging as the user you set up the authentication for:

user1@anothermachine ~ $ ssh user@machine.ip 
Verification code:

SSH should ask you for the verification code. Open the application on your phone, type the code and log in.

Linux machine 3.10.18+ #594 PREEMPT Wed Nov 13 17:59:34 GMT 2013 armv6l Last login: Thu Nov 28 11:08:16 2013 from anothermachine 
user@machine ~ $

Unless you screwed something up while configuring the authenticator, you should log in correctly.

Disabling 2FA

To disable 2FA, simply delete or comment out the previously added line in the /etc/pam.d/sshd:

# auth required

set the ChallengeResponseAuthentication inside the /etc/ssh/sshd_config back to no and restart SSH service.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket