6 ms·

Using a third-party service like authy.com has its advantages, but if you prefer, you can get two-factor authentication in the latest Ubuntu without involving a

• danielpal 14y ago
  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.
  • cs702 14y ago
    danielpal: google-authenticator prints out emergency scratch codes you can use if you lose your cellphone :-)
    • danielpal 14y ago
      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.
      • halostatue 14y ago
        My scratch codes are in 1Password (for my personal accounts) and LastPass (for work accounts).
        • charliepark 14y ago
          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.
      • Karunamon 14y ago
        >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.
      • arjunnarayan 14y ago
        Mine are written down in a post-it note stuck to the inside back-flap of my passport.
      • ikonst 14y ago
        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.
      • dalore 14y ago
        Mine are printed out and stored in my safe. They are never used.
      • pooriaazimi 14y ago
        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.
  • keidian 14y ago
    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
    • j_s 14y ago
      A ForceCommand example (for Yubikey) is documented here: http://www.tuxz.net/blog/archives/2010/03/17/how_to_quickly_setup_two-factor_ssh_authentication/ http://www.tuxz.net/blog/archives/2010/03/17/how_to_quickly_...
    • rsync 14y ago
      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...
  • jlgreco 14y ago
    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.
    • guiambros 14y ago
      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.
      • meik 14y ago
        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 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.
  • ikonst 14y ago
    I use ssh keys with this setup. If I login with an ssh key, I don't need the OTP.
    • vegardx 14y ago
      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.
  • dalore 14y ago
    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.
    • count 14y ago
      And how do you do that with cloud instances? :)
      • Ralith 14y ago
        Same way you do when you forget the root password on a normal configuration.
      • pixelcort 14y ago
        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 http://www.linode.com/faq.cfm#do-you-provide-console-access
      • justincormack 14y ago
        Install a new instance! Its all disposable hardware.
  • gregwebs 14y ago
    If you use a google voice number you can just point it to a new phone.
    • justincormack 14y ago
      Don't you need to login to do that? Using 2 factor auth..
      • ikonst 14y ago
        Yes, so use your backup keys, or a secondary phone number, or a secondary email address... plenty of options.
• jlgreco 14y ago
  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).
  • Ralith 14y ago
    Most probably, they didn't know about PAM.
    • danielpal 14y ago
      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.
  • danielpal 14y ago
    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.
    • jlgreco 14y ago
      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.
• ersii 14y ago
  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 :-)
  • paxswill 14y ago
    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/ http://code.google.com/p/google-authenticator/ [1] http://en.wikipedia.org/wiki/HOTP http://en.wikipedia.org/wiki/HOTP [2] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...
  • drivebyacct2 14y ago
    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/ http://code.google.com/p/google-authenticator/
    • pja 14y ago
      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?)
      • mryan 14y ago
• draebek 14y ago
  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.
  • jiri 14y ago
    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.