Securing SSH with Google Authenticator

In my old blog post, I talked about how to mitigate from persistent SSH brute force attack. While there are several options in mitigating SSH brute force attack, I opted to use the Fail2Ban option at the time. Today, I’ve decided to add another security layer to the host since this is a public facing server. This addition of security layer is based on defense in depth, which is an information assurance concept. As the title says, I will be using Google Authenticator to generate a time-based one-time password (TOTP) for two-step verification.

It seems like two-factor authentication (2FA) is becoming a norm these days. More and more security professionals are pushing organizations to use 2FA for every sensitive systems and application. Understandably so, because the consensus is that password is no longer enough to protect accounts in this day and age. As a result, I’ve also decided to start implementing 2FA in my home devices.

Installing Google Authenticator PAM

Ubuntu has been my distro of choice for several years now, so all of my Linux-related tutorials have been on that. I will keep that going, mostly because I do not have time to learn another distro, like CentOS.

Installing Google Authenticator on Ubuntu 16.04 is a piece of cake. All you need is one command.

$ sudo apt-get install libpam-google-authenticator -y

Configuring SSH PAM

The Google Authenticator 2FA is accomplished by integrating into Linux’s Pluggable Authentication Modules (PAM) library. PAM is a way for programs to use an underlying authentication mechanism. With that said, we’ll need to configure PAM configuration to pass it to Google Authenticator. To do this, we need to edit the PAM configuration file for SSH.

$ sudo vi /etc/pam.d/sshd

At the bottom of the file, I added the following lines below. The first line is optional, but it’s always best to add comment lines in my opinion.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

If you want to understand the syntax, please check this site. Though, the article did not include what nullok argument means. The argument simply means that if a user hasn’t created secret key yet, then they’re still allowed to log in. My recommendation is to enable 2FA for all users so make sure to have all the users generate the secret key. Once all secret keys are generated, take out the nullok argument.

Configuring OpenSSH Daemon

The next step is to actually configure SSH to check for backend system (e.g. PAM) to use the challenge-response authentication method. To do this, we need to edit the OpenSSH configuration file.

$ sudo vi /etc/ssh/sshd_config

Once the file is open, look for the line with ChallengeResponseAuthentication no and change it to yes. Save the file and exit.

ChallengeResponseAuthentication yes

In Linux, changes to Linux configuration files require a service restart to take effect, for the most part. With that said, we need to restart SSH daemon (sshd). To restart SSH service, issue sudo service ssh restart command. Once sshd is back up, test to make sure that user can still log in without two-step verification.

Generating Google Authenticator Secret Key

The last step to make SSH 2FA work is to generate a secret key for the two-step verification. In this example, I created a test user account for demo purposes.

Use the Google Authenticator app on your mobile device and add the QR code.

Account with Google Authenticator secret key

In this example, SSH daemon is asking the user to enter Google Authenticator OTP.

$ ssh test@radius
Password: testing1234
Verification code: 664449
<-- Output omitted for brevity -->
test@radius:~$

Account with no Google Authenticator secret key

Here the admin account does not have the Google Authenticator secret key yet. If one forgets to add the nullok argument, then the system will not allow user accounts without the secret key.

$ ssh admin@radius
Password:
<-- Output omitted for brevity -->
admin@radius:~$

Optional Configuration

It is probably a good idea to enable 2FA to the local login (console) too. So this way, anyone who has access to the physical machine will be subjected to two-step verification. To do this, we need to edit the login configuration file.

$ sudo vi /etc/pam.d/login

Once the file is open, add the lines below at the end of the file. Save the file and exit out.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

From now on, all user accounts with Google Authenticator secret key will need to enter a verification code.

Thoughts

Balancing security and convenience is one of the biggest dilemmas that information security professionals face. In a nutshell, making it convenient for users to access their account means it is less secure. In a perfect world (no bad guys) people would probably pick one password across all of their accounts. Since we’re not living in a perfect world, this leaves the accounts to be very insecure. If one account is compromised, then all of the other accounts could potentially be accessed by the bad guys.

The use of complex passwords and password managers are good first steps toward securing accounts. However, in today’s world, some of the information security professionals view password alone as an antiquated technique in securing accounts. As a result, a lot of online services have had multi-factor authentication feature. However, companies that provide these online services do not force accounts to use it. As a result, accounts are still at risk by relying on passwords alone.

You might also like to read

Adding Two-Factor Authentication to FreeRADIUS

Reference

How to Secure SSH with Google Authenticator’s Two-Factor Authentication

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.