Header-Ad

PHP,Joomla,WordPress & Linux based server management, error resolutions and fixing problems.

Sunday, November 13, 2016

How to Secure SSH using Two-Factor Authentication? [SOLVED!]

How to Harden SSH?


As part of the Authenticator project Google released a PAM (Pluggable Authentication Module) implementation of the 2-factor system. This is readily available and packaged as libpam-google-authenticator on Debian/Ubuntu.
Once installed, you can run google-authenticator to generate your user’s secret and configuration settings. Just follow the prompts and scan the ASCII QR code to add it to the Authenticator app.
You can then add auth required pam_google_authenticator.so to /etc/pam.d/sshd. You’ll also need to have ChallengeResponseAuthentication yesin your /etc/ssh/sshd_config.
This way, when you log in with a password, the system will request your one-time token as well.

The reason this is less than ideal is that any sufficiently hardened setup already disables password logins. What I wanted in my particular case was a public key login with a mandatory second factor. Turns out, however, that public key login completely bypasses challenge-response login.
After some searching, I found the AuthenticationMethods sshd_configparameter. Adding the line
AuthenticationMethods publickey,keyboard-interactive:pam
to my sshd_config did indeed prompt me for my verification code. But not before prompting me for my password as well. This was a bit too much, so I set out to limit the login sequence to just a prompt for the code.

PAM is magic

The reason this was happening was that publickey,keyboard-interactive:pamrequired a successful complete PAM run before letting you proceed onwards. My PAM config (in /etc/pam.d/sshd), however, was asking for a password and I’d added the line at the end to also ask for a verification code.
I moved the line to the beginning of the file and changed it so that it is enough to log you in:
auth sufficient pam_google_authenticator.so
However, pressing Ctrl+C or entering an empty code at the 2FA prompt still dropped me to a password prompt. This would clearly not do.

The solution

Turns out, sufficient is an alias for [success=done new_authtok_reqd=done default=ignore]. Notice that the default action is ignore. That is, the module is sufficient to authenticate me but not required.
The final solution was to prepend the following to my /etc/pam.d/sshd instead:
auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok
The nullok option means that if the user doesn’t have 2FA set up, the module will still let you through.
I also left the rest of /etc/pam.d/sshd intact, even though it’s unnecessary now - the 2FA module either kills authentication or declares it complete, nothing else should ever execute. That said, PAM is magic and I’m no wizard.
I hope I freed someone’s afternoon for better things than fiddling with ssh and google-authenticator.

No comments:

Post a Comment

** Comments are reviewed, but not delayed posted **