Google’s new do-it-yourself two-factor authentication (Google Authenticator) enables you to setup stronger logins on your linux system. Nick Wilkens (@nwilkens) has a good/quick tutorial up on his company’s blog for acquiring, compiling and setting up Google Authenticator for ssh sessions.
NOTE: On the Ubuntu VPS I was doing testing on, I had to add the libpam0g-dev & libpam0g packages to get Google Authenticator to work.
I’m pointing out the obvious (if you’ve read either Google’s link or the tutorial), but the Authenticator comes with a PAM (pluggable authentication module) library that literally just drops into any pam configuration file. This means you aren’t limited to the ssh integration, which opens up many possibilities (one of which is mod_auth_pam for Apache which I haven’t tried yet).
I would argue that there is limited value from the ssh integration as most folks probably have certificate login enabled. However, one area that I can see being of interest is in securing use of su to root. If you have more control over who has the ability to perform full privilege escalation, your system is that much less at risk from being usurped or accidentally broken (there’s actually a whole company built around that concept).
Detractors will point out that VPS setups would still be at risk from hosting admins having virtual disk image access and may further point out that even a locked cage in a hosting data center can be bolt-cut, but I would argue that the whole point of engaging in such a pursuit would be to reduce risk to your environment (not eliminate risk).
I will say that securing root su with two-factor authentication while doing nothing to secure sudo is pretty much pointless. If you have no restrictions on sudo, anyone who gains control of an account that is allowed to sudo with superuser privileges will be able to bypass your two-factor su config (and could compromise the integrity of your system even without root su access). Also, if you have more than one user who needs access to root su, you will be sharing the authenticator setup with them.
I still believe this is a worthwhile exercise even with those caveats, especially since it’s so simple to setup/teardown. After getting the Google Authenticator installed, issue google-authenticator from your root account. Transcribe and secure the QR code URL, secret key, verification code and emergency scratch codes in the event you have problems with you digital authenticator app (I keep the scratch codes on a small piece of paper that is always with me and stored securely at home as well).
Use manual input or the QR code scan to add the account to your authenticator app and then make the following addition to the /etc/pam/su config file:
auth required pam_google_authenticator.so
[/sourcecode]
I have mine before all the session configs.
When you issue your “su –” command you will be prompted for both the code and the root password:
$ su –
Verification code:
Password:
[/sourcecode]
I’ll be experimenting with integrating Google Authenticator with various administrative login systems (e.g. WordPress, Drupal) and maybe even as a generic auth module for various web app frameworks and would be interested in any other uses you have for Google Authenticator
3 Comments
I would actually do it the other way around — lock totally su for any other user than root and secure sudo with Google Authenticator (:
Hadreta, I’d agree with you, but the Google Authenticator configuration is viewable and configurable by users once they’re logged into their accounts. Securing sudo with Google Authenticator could be easily sidestepped by a simple ‘cat ~/.google_authenticator’ without some modification.
I put this in /etc/pam.d/common-auth so it affects SSH, su, and most other services. I can’t say whether it works for all PAM clients, but it does for both SSH and su.