5 issues enterprises should consider before using Google Authenticator for SSH

Posted by:

admin 9 years, 9 months ago

There's been a plethora of blog posts on how to add Google Authenticator to SSH on Linux.  Two-factor authentication for SSH is a great, great idea. no doubt about it.  We've done SSH tutorials at least since 2007, some earlier.   If you are adding two-factor authentication to your home server or single server, then Authenticator is a fine choice.  However, if you are a business or an organization with more than one server, you should consider these 5 issues before proceeding:

1.  What are your support options?

The PAM module is an un-supported 'example' module for PAM. There's no throat to choke, should you like throat-choking.

2.  How will this work with your VPN?  Etc?

Now that you have two-factor authentication working for SSH, what about your VPN? I think it's better to pick a standard authentication protocol that you know works with all enterprise class remote access services and directory infrastructure and work backward from there.  Inside the firewall, that protocol is almost always RADIUS.   You do not want to create a separate identity infrastructure just for SSH.

3.  Why add a step to the auth process?

Authenticator only provides one factor, proof of what you have (your smart phone).  The PAM module first makes you login with your username and password and then adds a step - you provide the OTP from your device.  I understand why they did it this way. It would have been much harder to have the user login with their username and the OTP + a PIN. PAM allows and encourages this type of chaining.

However, I think it's a wasted opportunity to eliminate a use of passwords.  I also think there's a security benefit in not using passwords outside the firewall.

4.  Google Authenticator after 2.2.1 is no longer open source.

Most people think that it is open source.  The Authenticator token client is no longer open source.  The PAM module is, but that's only part of the whole solution.  You have one license for the server piece and another for the client.  Are you ok with that?  Why did Google change the license to the client?

5. Google Authenticator uses shared secrets and therefore doesn't scale well across servers.

How will many servers do you have? Are you willing to share secrets across all those servers?  Or have a google account for each one? How scalable is this solution? The developers of module have said that it is not.

Since Google Authenticator uses a shared secret (WiKID uses public/private keys) that shared secret needs to either be on every server or each server needs to be listed as an account on your Google Authentictor token client.  There is no centralized auth server.  Any server that is compromised has the shared secret and leads to the compromise of all the other hosts or you have dozens of Authenticator listings - one per server.

UPDATE: If you are doing 2FA for PCI DSS requirements, note that the PCI council has stated that mutli-step authentication is not acceptable.  You must use true multi-factor authentication.

Of these, number 5 is the deal killer.  Such catastrophic failure is not ok.

• ← Are we royally screwing up two-factor authentication
• New VMWare Two-factor Authentication Virtual Appliance →