Here's how you do it: first, sudo apt-get install libpam-google-authenticator; second, run google-authenticator as the user you will access remotely and follow the instructions; then, edit /etc/pam.d/sshd, and add "auth required pam_google_authenticator.so" in a new line; edit /etc/ssh/sshd_config and add (or change) the ChallengeResponseAuthentication line so it reads "ChallengeResponseAuthentication yes"; and finally, sudo service ssh restart to restart the ssh server.
More info is available from the packager of libpam-google-authenticator, and from the Google Authenticator PAM module's README.
Edits: Corrected typos; added more context.
Also what happens if you loose your cellphone? We thought about this and for us the possibility of loosing access to the server fully was too much.
If not, it might be possible to configure PAM with some sort of keys module set to 'sufficient', then have PAM fall back on two-factor auth paired with pam_unix.
In fact, I'll see if I can get either of those working a bit later today. Seems like it could be neat.
Of course this leaves you a vulnerable to ip spoofing, but adds a ton of convenience and could be a good trade-off.
But that's correct, in recent openssh versions, it seems that you can add specific-host-only rules for authentication etc.
I also believe I once ran across a patch someone had done to the login code to allow both to be required, I can't find the link right off though as I'm at work currently. If I find it, I'll add it here
This is on our list to pay for someone to do, and we'll release it when they do ... it will probably be FreeBSD-centric, but if it's against OpenSSH generally, it should be usable by others...
Then that's a process problem that can be solved. It would take a trivial amount of time to screenshot the page and stash them in your wiki or similar.
I've written down mine on three different pieces of paper (in my wallet, my bag and my closet), and also took a screenshot from it and `gpg`-ed it (with a passphrase, so no one can open it unless they know the password) and stored it in a few online repositories, as well as a friend's mailbox.
So, I'll never be locked out from my account.
This is your problem. I keep mine (for multiple services) in my wallet, and it's worked out excellently.
Anyone set up Google Authenticator to only challenge me on a host every N minutes or something like that? I.e., first login requires two-factor auth, subsequent logins don't for at least 30 minutes? Seems like it'd be irritating to keep popping my phone out every time I connect to a remote server.
Unless I'm mistaken in how Google Authentiator works - of course. If so, please fill in my blank :-)
So you are in fact handing over your 2-factor auth key to Google when you run google-authenticator. There's no actual need for the binary to do this (although it obviously makes the key entry on the phone much less error-prone) and there don't seem to be any command line arguments that would turn it off either. doesn't do this at all -- see below. (can I do strikethrough on HN?)
So you are in fact handing over your 2-factor auth key to Google when
you run google-authenticator
If you visit this URL, you are sending the "QR-encoded" (not exactly, but you know what I mean) version of the key to Google's servers.
As long as you do not visit this link, you will not send your key to Google's servers.
So don't hit that URL if you don't want Google to know your 2-factor auth data!
Also, the way I would intend on using this is such that if your public key is in authorized_keys, you log in like normal. If not, you authenticate with PAM using both your unix password (or ldap or whatever you have configured) and your 2nd authentication system. I log into one or two of my servers from strange computers often enough that disabling password authentication entirely on those servers is limiting.
Off-topic: Has anyone ever managed to get PAM/Google Authenticator working with RADIUS? I spent a while messing about with this last year, and never got it working exactly as I had hoped. I'm no longer working with RADIUS, but this post reminded me I never finished scratching that geeky itch.
For FreeRADIUS we use rlm_perl to define our own authenticate() method; it just calls the web service to validate the codes.
If you lose your phone and your scratch codes, you've only lost access via SSH. So it's an inconvenience, but one you can overcome with the right setup.
Yes, if you lose either factor, you can't access the server. This is why with Google Authenticator you also get a one time pad with emergency codes. However, I don't know how well this would work with two-factor SSH... you'd need a separate one time pad for each server. And I'm not sure how the Google PAM module handles emergency codes.
While this one isn't quite as offensive as some, all these curl/sudo/bash combos really make me sad, particularly when used to "increase" security.
If you start pushing insecure technologies like this, people will just get really comfortable with them and eventually get taken advantage of.
A secured data connection is much better than SMS and easy to implement. But this is still a 'something you send' factor, which can be intercepted. A physical token or 'something you have' is more secure, and can also be easily implemented with a YubiKey, a paypal/ebay authentication card, etc.
If you think your data is so valuable someone might install a keylogger to get it, you might as well secure it as well as you reasonably can.
Yes, SMS can be broken. I'm sure Google Authenticator is vulnerable to certain attacks, too. Using them is better than throwing your hands up in the air and saying "it's not perfect, we'd better not implement it because then people will act as if they have perfect security!" Because people are already acting like they have perfect security.
Yeah, SMS isn't perfect, and yeah, it's better than nothing. But you know what else is better than nothing? Properly implemented TLS from an app or website on the phone. Of course that has holes too, but it's encrypted and (hopefully) authenticated unlike SMS. And it's available in every phone that can do SMS (unless you don't pay for data).
You can do whatever you want. But if you give people a crappy option and a good option, and the crappy option is slightly easier, they'll use the crappy option. But if they want the extra security they'll use the extra click it takes to make the good option work. Most people will just reason that nobody will ever use a keylogger on them and keep using keys with passwords.
Missing. The. Point.
I know that's reasonably secure but it feels terrible.
Default action when api.authy.com cannot be contacted:
1. Disable two factor authentication until api.authy.com is back
2. Don't allow logins until api.authy.com is back
I've been using them across a half dozen personal machines for quite a while now, looking to roll it out at work as well.
Also, it occurs to me: With TFA, it finally makes sense to periodically change passwords.
No, the reason nobody (in and only in the US) uses 2FA (because nearly every other country in the world uses it widely) is because it's a pain to use for the end user. No enterprise is going to invest their time and energy into a solution unless they're either required to by regulations or is truly better, easier, more secure, or whatever than competing solutions to make it a compelling sale.
If this were a hobby project then I'd be cheering you on -- why not make a token 2FA with a slightly better API? But as a YC-funded company whose likely avenue of success will be through the enterprise market, you NEED to develop a product that is better, faster, easier, more secure, etc than your (rather formidable) competition.
Trust me, I'm familiar with this market ;).
If somebody went through the trouble of owning your machine, can't they bypass the two-factor as well? Yes, it requires a more "live" and target attack, but one would think ssh attacks like these are pretty targeted in the first place.
Or? What am I missing?
Who talks about a machine that is owned? This is about an additional requirement to log on to a service, be it ssh or email. Whether you're reusing your password, sharing it or just use a really bad one this adds an additional step to impersonate you.
Otherwise though, I do think that this is an awesome idea. It only needs apps for smarphones instead of sending an SMS and you're on part with Google and Battle.net :)
Though I haven't checked ;)