We've been using libpam-google-authenticator for a while on all our servers, it's part of our base Chef configuration.
Our setup is that key based authentication works as normal, but if you want to use a password based authentication, you need to 2-factor auth.
This approach allows us to maintain security without losing the ability to go "Oh no I'm somewhere without any of my private keys and I really need to log into that server to fix this production error!"
It would be great if this was supported along with key based authentication. Using the PAM method outlined here works only with password based authentication and the TFA is completely bypassed when a key is used.
I researched this a few months back and was not able to find a clean way to add TFA to a key based login. Any suggestions from other HN readers?
The latest version of OpenSSH (6.2) has added the AuthenticationMethods configuration option which allows you to specify multiple required methods, like publickey + password. With UsePAM 'password' should be passed to PAM, and in turn Google Authenticator (which would be like 3-factor auth). [1]
Red Hat added a similar though slightly different patch with RequiredAuthentications1 and RequiredAuthentications2. They patched OpenSSH 5.3 in RHEL 6 (and CentOS) as of 2012-06-20. [2]
So instead of Google Authenticator you could use publickey + password for 2-factor auth.
In addition to what antoncohen wrote, I've seen a lot of people suggest using ForceCommand in sshd_config to run something that will check the Google authenticator code after you've completed key-based authentication. I think ForceCommand has been in sshd for a while, and it might be more suitable for some environments.
I don't get it why standard TOTP is suddenly Google something. Afaik, it has nothing at all to do with Google. Except adding Google something make it sound better? Maybe if I use TOTP app with my iPhone then i get really cool Apple iAuth?
Google Authenticator only offers a subset of standard TOTP, and it also offers a very similar subset of HOTP.
- Option of TOTP or HOTP ("time-based" or "counter-based")
- SHA1 only
- 6-digit codes only
- 30-second time step only (TOTP)
- Base32-encoded keys only
"Google Authenticator" also implies that the secret is stored on your phone, where it's far more susceptible to remote compromise than if it were stored in a dedicated hardware TOTP token.
Personally, my preference for SSH two-factor authentication is to just use standard pubkey authentication, but only allow keys that have been placed into PIN-protected, tamper-resistant hardware. The crypto is stronger, it doesn't involve some obscure PAM module, and the attack surface is smaller (since you can avoid invoking PAM at all until after authentication succeeds).
> The crypto is stronger, it doesn't involve some obscure PAM module, and the attack surface is smaller (since you can avoid invoking PAM at all until after authentication succeeds).
And your ability to access to your hardware isn't dependent on an external organisation. I mean its not unheard of for Google to close down accounts from time to time. I wouldn't want my keys in somebody elses safe...
According to the gauth “disclaimer” on the website, the recent versions of the Android app are proprietary: the most recent on Google Play is from February 13. It’s hard to tell if there will be any more commits to that repo.
Have there been any vulnerabilities found? It's just another implementation of HOTP (RFC 4226), so that would be pretty important.
I'm not sure about the details of MOTP, but I can't find much chatter elsewhere about it. I would need much more before I recommended it to anyone as an alternative.
(and that fork is just a one-off fork of the google repo, with only two changes made to the README since forking)
There's quite a few PAM modules like this for SSH authentication. Another one I was trialling for a few weeks sometime last year was captcha codes (basically written in ASCII art) to prevent automated attacks. Sadly it quickly became more of a nuisance as keys and/or fail2ban/denyhosts/etc already do a better job of that and don't have the downside of an annoying additional verification stage.
I would highly recommend using DuoSecurity for all your 2-Factor Authentication needs. Their solution is very slick, easy to use, and intuitive. Duo has options for every conceivable situation a user might get themselves into including Push Notifications, SMS codes, saved bypass codes via SMS, static bypass codes, phone calls, and hardware keys including YubiKey support. Additionally, they have APIs that expose any of the data/functionality you wish and native language support including Python. You can drop in their plugin to protect WordPress with a couple clicks, add support to your internal applications via Duo Web, protect your Splunk install, SSH connections, SSL VPN, and a ton of other possibilities. Also, they have a freemium model where your first 10 accounts are always free.
Nope. Sorry if it came across that way. I am just a happy customer that loves their product. Others have mentioned Duo on this thread (and other HN threads too...) Great product, great support, reasonable price.
Thanks for the amazing feedback, we're extremely happy you enjoy Duo so much. Please keep in touch if there's anything we can do to help make your experience with Duo better; we're always working hard on new integrations and platform features.
Most of our integrations allow for a configuration of "failmode" that allows for deciding how to handle unreachable/bad configuration scenarios. From our docs: "On service or configuration errors that prevent Duo authentication, fail "safe" (allow access) or "secure" (deny access). The default is "safe"." Check, https://www.duosecurity.com/docs/duounix, for an example of this in actual documentation. Great question!
In terms of SSH, one of the features of Duo is that you can have many methods to authentication... push to phone, phone call, sms, yubikey, etc -- having that list allows you to pick how upon login.
We're definitely a SaaS provider so going through us is part of our service -- this also allows us to handle things such as telephony needs, push notifications, etc. for customers.
In terms of technical information, is there a specific feature or technology you're interested in knowing more about?
Thanks again for releasing this, we're always excited to promote open-source work and release as much of our own as possible, https://github.com/duosecurity
Very nice company, great android app, but unfortunately it doesn't have an approve/deny button right on the notification on android. That's the only think I miss.
Nice idea. However, would there be any security enhancements over using key based authentication where all clients have full disk encryption on them? The only thing I imagine this protecting against (when using key based auth) is if my laptop were to be stolen, which is already protected by the full disk encryption. Am I missing something or is this primarily for password auth?
I suppose automated deploy scripts could also be modified to accept an authenticator code as a parameter too.
> However, would there be any security enhancements over using key based authentication
I think you're misunderstanding. Two-factor authentication is a layer of security on top of regular authentication to ssh (whether password or key based). It's not meant to replace anything or stand on its own. This is for added security; first you authenticate via password or key, and then you authenticate via google authenticator.
By design TFA uses something one possesses that nobody else does, isn't this identical in principal as the private key?
I understand why and how this adds the extra security for the 'traditional' password authentication due to all the methods of compromising a password: brute force, guessing, exploits etc.; so for TFA to add an extra layer surely the private key would have to be exploitable in some form?
Maybe I phrased myself incorrectly in that I still see how it adds an extra layer of security but I fail to see why one would do this on top of a key based auth method.
I know the original article didn't mention using it on top of key auth but I wanted some insight as to whether or not it would be worth doing. As do many, I use TFA for any online service I can so I do appreciate its point in that sense.
EDIT: I never really considered the fact that the private key could be stolen via malicious software. Taking that into account I see the value in TFA for SSH.
The major advantage is that the OTP secret is stored elsewhere - not on the machine authenticating.
If it is, it doesn't really add any security.
Morever, if the servers you authenticate too all share the same secret (ie you use the same token with all of them), you're decreasing the value of the 2nd factor by the amount of servers.
That's because anyone getting access to those servers can generate your OTP and connect to the other servers (if they also have the SSH key).
One way to mitigate that is to have a centralized authentication server for OTP.
All in all, if you want to protect your secret, OTP isn't the best solution. It's just something convenient.
I would recommend using an openpgp smartcard instead.
Two factors is better than one, but people are at risk of their Android phones being compromised too, maybe as much as most Linux boxes. If your phone is not fresh off the assembly line, you're surfing the web with ancient unpatched WebKit and an OS that has a zillion unpatched local root bugs. If you use a password storage app on your phone, that's both factors on it...
Please fix your blog so it doesn't disable zooming on iPads (and possibly other devices). There is no good reason for doing it and it prevents some people from reading what you wrote.
It uses libpam-google-authenticator, looking at the source for google-authenticator.c[0] (line 156-7) it appears to use the Google Chart Infographic[1] API (which as a side note has been officially deprecated).
Can't quite work out how it is displaying it, I'm not competent enough with plain old C, but I'm sure someone can follow the code and chime in.
EDIT: Looks like it uses libqrencode and if that's not found it just uses Unicode block elements for actually displaying it from Google's API.
The title of the blog is ... "Linux Blog" and the author may very well have no time/resources/desire to check whether his writing is also applicable elsewhere.
Our setup is that key based authentication works as normal, but if you want to use a password based authentication, you need to 2-factor auth.
This approach allows us to maintain security without losing the ability to go "Oh no I'm somewhere without any of my private keys and I really need to log into that server to fix this production error!"