Last week, Google enabled two factor authentication for everyone. This article explains how to install and configure Google Authenticator in conjunction with SSH for two factor authentication. Two-factor authentication relies on something you know (a password) and something you have (your phone).

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) y

Note: The emergency scratch codes are one-time use verification codes in the event your phone is unavailable.

Configure this new secret key in Google Authenticator

In your Google Authenticator application on your phone, add this new secret key that was generated in the previous step. Note, a URL is also displayed, that can be scanned from your Google Authenticator application.

Wrapping up the setup

You will now need to restart SSH for the pam/ssh changes to activate.

At this point, you will want to stay logged into the server while you test in another shell.

I’ve set this up on several Linux workstations and servers, some of which I also use ssh keys with. To my knowledge, the keys overwrite the need for the 2FA, which doesn’t bother me, since I’m more worried about intruders from outside versus intruders from what I consider trusted boxes (which they, themselves, are set up with 2FA, so in theory, barring a security hole, they shouldn’t get access to anyway).

One of the bugs I’ve encountered (and I don’t know if it’s fixed yet) is that if you have a server and you want to make 2FA optional, the original code would not allow people who didn’t have a .google_authenticator file to log in, even if their password was correct. The issue was/is fixed with the patch found http://code.google.com/p/google-authenticator/issues/detail?id=18

Also, I had tried this on a server with AFS….after applying the patch, if the user was set up for GA, then they could log in as expected. However, if a user was not set up for GA, they could log in, but wouldn’t receive their AFS token. I don’t know if there’s a workaround for that….

But, all in all, I love this and have it set up to not only protect ssh, but initial log in and when my screensaver locks on my workstation at work.

RCDevs OpenOTP also has a nice interface and full blown server platform with RADIUS, SOAP and PAM and Google Authenticator.
It works with LDAP acounts. It’s very convenient for a PAM-LDAP + Two-factor with GA.
Found it here : http://www.rcdevs.com

I know pconwell’s problem is over a month old, but in the interest of possibly helping someone else with the same issue, I’ll post what worked for me.

I got the same error messages in my build and traced it to the fact that I am using a 64-bit version of CentOS. That means the libraries are in a different location. The offending library reference in the Makefile is /usr/lib/libdl.so On my system they are located in /usr/lib64 but yours may be different so try to track down where it is first.

All I needed to be do was to edit the Makefile and replace any occurrence of /usr/lib/libdl.so with /usr/lib64/libdl.so

I don’t have the link, but someone has submitted this issue to the Authenticator project as a bug, so hopefully it will be fixed someday soon.

If you get
pam_google_authenticator.c:41:34: error: security/pam_modules.h: No such file or directory
pam_google_authenticator.c:65: error: expected declaration specifiers or ‘…’ before ‘pam_handle_t’
…
run
apt-get install libpam0g-dev

With regards to the SSH Key issue: I think this is by design and not a bug.
SSH Key Login already *is* two-factor authentication if done according to best practice:
1. Something you have – your encrypted SSH privkey
2. Something you know – the passphrase für said privkey

Thus, using the same factor again (something you have – totp token) does not increase effective security because you still only have two factors.

In addition to remote logins via SSH, you can also use the PAM module to protect su. Just insert the line
auth required pam_google_authenticator.so
in /etc/pam.d/su
I don’t think there are repercussions for cron etc., but I might be wrong. It works fine on my test machine, though.
I didn’t test it, but this should also work for sudo, which is obviously a nice-to-have for Ubuntu users.

This works with the package ‘libpam-google-authenticator’ in the Debian testing repo. All that’s required are the lines in /etc/ssh/sshd_config and /etc/pam.d/sshd, and it just works. If a public key is available then it will be used in preference to the Google Authenticator code.

There’s an option to enable rate-limiting, which “limits attackers to no more than 3 login attempts every 30s”. That means it would take over 31 years to test all possibilities of the 8 digit backup codes. And you would still have to brute force the SSH password (and the username, since root login should be disabled) as well. You should also have something like fail2ban – http://www.fail2ban.org/ – running on your server.