The biggest problems is you can't use ssh_keys with this setup. Its too restrictive, and certificates are a must for ssh.

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.

Unless I am mistaken, it should be possible to configure opensshd to first try using keys, then fall back on UsePAM only if that fails (similar to how sshd will normally fall back on PasswordAuthentication).

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.

Another option is to whitelist your ip address, and then require 2-factor auth only when you're connecting from a non-whitelisted ip address.

Of course this leaves you a vulnerable to ip spoofing, but adds a ton of convenience and could be a good trade-off.

Yeah but (blind) IP spoofing over the Internet is infeasible nowadays. Maybe 15 years ago when ISN randomization was not the rule (successful attack described in http://web.textfiles.com/hacking/shimomur.txt)

But that's correct, in recent openssh versions, it seems that you can add specific-host-only rules for authentication etc.

You could probably do a hack to let the user login with ssh key and then immediately force the second factor auth to be run, booting the user out if they didn't pass it. Not the best way, but one option.

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

A ForceCommand example (for Yubikey) is documented here: http://www.tuxz.net/blog/archives/2010/03/17/how_to_quickly_...

Yes, I have seen a patch as well that allowed you to require both an ssh key and a password ... it was an old patch, though, and I can't imagine it would apply cleanly to any recent OpenSSH ...

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

What happens if you lose your normal password? Why you boot up into single user mode using the console like the old days of when you forgot the root password.

And how do you do that with cloud instances? :)

Some VPS providers offer "console" access to the machine, which would probably allow someone to drop down into single user mode.

http://www.linode.com/faq.cfm#do-you-provide-console-access

Same way you do when you forget the root password on a normal configuration.

Install a new instance! Its all disposable hardware.

danielpal: google-authenticator prints out emergency scratch codes you can use if you lose your cellphone :-)

Yeah but in reality no-one writes it down. I actually use Google-Auth for my Gmail, but I forgot were I wrote this number down(it was a couple of years ago). Keeping a scratch code for each new server is a pain.

>Yeah but in reality no-one writes it down.

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.

Those who don't write it down deserve to be locked out.

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.

It's the only sane thing to do!

My scratch codes are in 1Password (for my personal accounts) and LastPass (for work accounts).

People really should do this. It takes 10 seconds, and eliminates having any paper to lose (or keep secure). Copy and paste, and you're done.

Mine are printed out and stored in my safe. They are never used.

> Yeah but in reality no-one writes it down. I actually use Google-Auth for my Gmail, but I forgot were I wrote this number down(it was a couple of years ago). Keeping a scratch code for each new server is a pain.

This is your problem. I keep mine (for multiple services) in my wallet, and it's worked out excellently.

Mine are written down in a post-it note stuck to the inside back-flap of my passport.

You can use the same key for all the servers. Just copy the files generated by the 'google-authenticator' app. I don't see any less security in that.

I use ssh keys with this setup. If I login with an ssh key, I don't need the OTP.

How did you manage to do this? You'd have to use PAM for this to work, and PAM and key-based authentication is mutually exlusive, as far as I know.

If you use a google voice number you can just point it to a new phone.

Don't you need to login to do that? Using 2 factor auth..

Yes, so use your backup keys, or a secondary phone number, or a secondary email address... plenty of options.

Thanks for the instructions, I like the fact that Google Authenticator doesn't need to contact their servers (or at least that's how I understand it). Sounds like you could preserve the use of SSH public key authentication by using Google Authenticator in combination with a ForceCommand; I'll have to look in to that.

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.

Partial solution: it may be useful to use Host * and ControlMaster auto in your .ssh/config to reuse connection so you do not need to authorize all the time.

Google Authenticator is pretty much a third-party service as well.

Unless I'm mistaken in how Google Authentiator works - of course. If so, please fill in my blank :-)

Using pam-google-authenticator does not depends on Google, they just wrote widely available apps and a PAM module[0] that implement HOTP[1] and TOTP[2]. Basically, you have a seed and a counter that you hash together. When adding a device, the seed and counter are synced with the device. When logging in, the server generates the proper code, then verifies it got that code. The major difference between the two algorithms is that TOTP uses time as its counter, while HOTP uses a manually increased counter.

[0] http://code.google.com/p/google-authenticator/

[1] http://en.wikipedia.org/wiki/HOTP

[2] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...

You are mistaken. I'm not sure what blank to fill in. Google Auth use OATH for their two factor auth. Using the reference package just gives you their PAM module. It doesn't require hitting their servers or anything.

http://code.google.com/p/google-authenticator/

If you run google-authenticator with no arguments it hits Google's servers in order to generate a QRcode for your phone to scan.

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

Unless things have changed a lot since I last used this, this is not entirely correct. The binary will print out a URL - the QR code is only generated if you hit this URL.

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.

Can't reply to mryan, but I'd just checked this before coming back to HN & indeed, google-authenticator doesn't make any network connections when invoked & it generates the QR-code locally.

So don't hit that URL if you don't want Google to know your 2-factor auth data!

Interestingly it appears this Authy method does not use PAM. I wonder if there is a reason for that, since a PAM module would be a good deal more flexible (this sort of thing is what PAM is for after all).

The basic reason is because we don't use passwords. We always use public/private certificates on all of our machines. With PAM you have to use passwords. We'll release a version soon that works with PAM, but I recommend you switch to using authorized_keys with certificates. Not only is it much more secure, it's also much nicer to use.

I do use authorized_keys, though PAM is good for a lot more than just sshd; that's why I say it is more flexible. For example, I could see two factor authentication being used to log into shared workstations through XDM/GDM. This would eliminate the possibility that your users are sharing passwords for their accounts.

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.

Yeah we'll release a PAM module soon so you can do this. If you don't want to wait, you could write one. Just look at this module, it's fairly simple. The API is really straight forward.

Most probably, they didn't know about PAM.

Not at all. We understand PAM and we plan to release a version that works with PAM. But we don't like passwords, we much rather use public/private ssh keys instead of users with passwords. It's not only much better user experience but is also much more secure.