Use Google Authenticator For Two-Factor SSH Authentication in Linux | Hacker News Reader

Use Google Authenticator For Two-Factor SSH Authentication in Linux

scottlinux.com

75 pointsvimes65648 comments

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.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=983

[2] https://bugzilla.redhat.com/show_bug.cgi?id=657378

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 got the ForceCommand idea from a thread last year about setting up two factor SSH auth using Authy: https://news.ycombinator.com/item?id=4444926

ForceCommand will not let you use SFTP or SCP due to the prompt. You do need the newer version of OpenSSH for proper MFA.

Hey Michael, you can try ours, it's specifically designed to work along with certificate's instead of passwords:

http://blog.authy.com/two-factor-ssh-in-thirty-seconds

(disclaimer: I am a founder of the company).

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?

It's called OATH btw :) (the standard that is)

That's the organisation behind the standard, not the standard.

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

The keys aren't stored on Google's servers, only locally on your phone. Closing your Google account wouldn't affect them.

rather http://motp.sourceforge.net/

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.

Fork: kaie/otp-authenticator-android https://github.com/kaie/otp-authenticator-android

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.

This comment sounds suspiciously like a sales pitch. Do you have a relationship with the company that you'd like to disclose?

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.

What happens if their servers are down for any reason? Are you unable to login?

Yes. https://www.duosecurity.com/sla

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!

Better yet, check out Duo Security: https://www.duosecurity.com/

It's free for individuals, and they even answer support emails ;)

(Undisclaimer: I have no interest in the company, just a fan)

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.

Thanks for the feedback, I've forward it on to our product and ux teams!

+1 for Duo. I actually wrote a Chef recipe for enabling 2-factor auth on Linux.

https://github.com/hungtruong/chef-duo-unix

It's my first recipe so feedback would be appreciated if you actually use it!

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

It looks pretty cumbersome to use with non-web apps. Either the app has support for it or..

According to the SSH screenshot you gotta choose the auth type, then enter the password or wait for auth.

In every case their central server seems to have authority over the 2nd factor, too.

Also, even the whitepaper is advertisement bullshit, no technical info. Is there any technical info anywhere?

We're definitely focused on making integrations as easy as possible. Check out https://www.duosecurity.com/docs/authapi and https://www.duosecurity.com/docs/duoweb for more on that.

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?

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.

I think oarmstrong's question is whether the two factors (key+TOPT) provides any real security over just key, assuming the key storage is encrypted.

That's what I meant, thanks. Don't know how I had such a hard time trying to explain that!

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.

I've never come across an openpgp smartcard, any particular one you recommend? I might look into this, seems like a very good idea.

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.

This protects you if someone manages to get a trojan into your laptop.

outside of desktop, if you're building a webapp, you should check out Prove.

we have a similar script to Stripe such that you can drop in a complete JS widget in seconds with your public API key.

  <form action="/verify" method="post">
  <script src="//getprove.com/v1/verify.js" data-callback="/verified.html" data-key="YOUR-API-PUBLIC-KEY" class="prove-verify"></script>
  </form>

https://getprove.com

(plug)

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

I have a blog post on how to enable google auth with openvpn

http://zcentric.com/2012/10/09/google-authenticator-with-ope...

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.

Cool I'll check that out,

Anyone happen to know what lib is used to generate the QRCode in the terminal?

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.

[0] http://google-authenticator.googlecode.com/git/libpam/google...

[1] https://developers.google.com/chart/infographics/

That's just for the URL. The QRCode in the terminal is generated locally using libqrencode and displayed using ANSI or Unicode chars, on function displayQRcode right below: https://code.google.com/p/google-authenticator/source/browse...

Just worked that out and then saw your reply. Shouldn't have doubted myself. You're clearly more knowledgable about this than I!

This isn't specific to Linux. Titles like this are off-putting to users of other open source OSes.

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.

Reply on news.ycombinator.com