2 Factor Authentication – Google Authentication

I had a requirement to enable 2 Factor Authentication on remote access to linux services migrated to the cloud. This solution can be utilized within any environment and also ticks some boxes for PCI compliance. To begin, I started looking for options that would solve my problem. Various products exist on the market that appear to work well. Duo Security, Wikid & Google Authenticator. I opted for Google Authenticator, as this is open source and seems to have more maturity within mobile devices (Android, Apple iOS etc). Source for Google Authenticator is available from Google’s code page (http://code.google.com/p/google-authenticator/ ).

Server Configuration

For my testing and immediate requirement I used Ubuntu Server 12.10. I began by downloading the Google Authenticator from the Apple iTunes Store. Then to complete the required configuration on Ubuntu Server 12.10

sudo apt-get install openssh-server lib-pam-googleauthenticator

To provide 2 Factor Authentication to SSH (remote access) you need to edit the following file;


Add the below line entry to the start of /etc/pam.d/sshd

auth required pam_google_authenticator.so

Now to update /etc/ssh/sshd_config to prompt for the “Verification Code”. Update ChallengeResponseAuthentication from no to yes.


ChallengeResponseAuthentication yes

We are almost done; you need to restart the sshd service to complete the configuration changes.

sudo service ssh restart

User Configuration

To generate the secret keys login as a user, run ‘google-authenticator’. This will generate a secret key, and add a file to your home directory that the newly installed PAM uses. Google Authenticator has options to access encrypted home directories see below for further details.


The following including a QRCode is displayed on screen. The QR Code contains all required information and can be used to import the data straight into the iPhone application.

https://www.google.com/chart?chs=200×200&chld=M|0&cht=qr&chl=otpauth://totp/[email protected]%3Fsecret%3D56RIII5VOZMO4W4I
Your new secret key is: 56RIII5VOZMO4W4I
Your verification code is 982248
Your emergency scratch codes are:

Following this you are prompted with a few different yes/no questions. These are self-explanatory and you can answer them as required.

Do you want me to update your “~/.google_authenticator” file (y/n)

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)

Phone Setup

In your Google Authenticator application on your phone, add this new secret key that was generated in the previous step.

Account: [email protected]

Key: Your Secret Key (highlighted in red above)


This completes the setup. Now you can test it by opening an ssh session to your server. You will be prompted for the username/verification code/password. Each time you log into your system, you will now be prompted for your TOTP code (timebased one-time-password) after having entered your normal user id and your normal UNIX account password

$ ssh [email protected]
Verification code: Your generated code from Google Authenicator
Password: Standard Password
[[email protected] ~]$

Additional Configuration Options

The following is taken from Google Authenticators read me file.

During the initial roll-out process, you might find that not all users have created a secret key, yet. If you would still like them to be able to log in, you can pass the “nullok” option on the module’s command line:

auth required pam_google_authenticator.so nullok

If you discover that your TOTP code never works, this is most commonly the result of the clock on your server being different from the one on your Android device. The PAM module makes an attempt to compensate for time skew. You can teach it about the amount of skew that you are experiencing, by trying to log it three times in a row. Make sure, you always wait 30s (but not longer), so that you get three distinct TOTP codes. Some administrators prefer that time skew isn’t adjusted automatically, as doing so results in a slightly less secure system configuration. If you want to disable it, you can do so on the module command line:

auth required pam_google_authenticator.so noskewadj

If your system encrypts home directories until after your users entered their password, you either have to re-arrange the entries in the PAM configuration file to decrypt the home directory prior to asking for the OTP code, or you have to store the secret file in a non-standard location:

auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google-authenticator

Make sure to set appropriate permissions. You also have to tell your users to manually move their .google-authenticator file to this location.



Arron Stebbing

Arron is a Channel Enablement Specialist for Veeam software covering the APJ region. Arron previously was an architect and built cloud services/solutions for service providers across APAC. Arron is a 6 x VMware vExpert. He is also a Subject Matter Expert and Technical Advisory Committee member for CompTIA helping author industry exams.

Comments are closed.