
Use Google Authenticator For Two-Factor SSH Authentication in Linux - vimes656
http://scottlinux.com/2013/06/02/use-google-authenticator-for-two-factor-ssh-authentication-in-linux/
======
davidbanham
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!"

------
mpetrov
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?

~~~
draebek
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>

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

------
Sami_Lehtinen
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?

~~~
dlitz
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).

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

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

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

~~~
magicalist
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)

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

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

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

~~~
markstanislav
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!

------
lawnchair_larry
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)

~~~
zobzu
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?

~~~
markstanislav
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?

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

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

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

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

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

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

------
niftylettuce
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)

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

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

[http://zcentric.com/2012/10/09/google-authenticator-with-
ope...](http://zcentric.com/2012/10/09/google-authenticator-with-openvpn-
for-2-factor-auth/)

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

~~~
scottlinux
Cool I'll check that out,

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

~~~
oarmstrong
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...](http://google-
authenticator.googlecode.com/git/libpam/google-authenticator.c)

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

~~~
icebraining
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...](https://code.google.com/p/google-
authenticator/source/browse/libpam/google-authenticator.c#177)

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

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

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

