SSH Access with MFA

Adding more Security to Secure Shell with MFA

Introduction:

Basically SSH is used to connect to a remote host over a secure channel. Why did i specifically mention Secure Channel? Can that be done insecurely as well? Yeah, using Telnet. Telnet is one more protocol which is used to do the same job but all the commands you execute on the remote host are sent in clear text. With this intro given, let’s get started.

SSH —

SSH stands for Secure Shell. In simple words get Shell access of a Remote Host Securely. SSH uses port 22 by default and it can be changed if required.

Need for MFA in SSH

Generally in SSH, authentication happens in these ways —

Username:Password login— Connect to the Remote Host on SSH Port and enter Username, then Password.
Public Key Authentication — Connect to the Remote Host on SSH Port with Private Key. SSH Server will have the corresponding public key to authenticate the user.
Combination of 1 & 2 — Connect to the Remote Host on SSH Port with Private Key, then enter Username and Password to get in.

In three of these methods, the Authentication method which is either Username/Password, Private Key or a combination of both, is static in nature. If an unauthorized user gets access to these credentials by some means, he/she can login into the Remote Host, given they have the network clearance. Remember internal teams would have the Network Clearance, most of the time.

So the idea is to introduce another factor into this authentication mechanism which ensures safety even after the Credentials are compromised. MFA does the job for us in this scenario. MFA stands for Multi Factor Authentication. Simply put, multiple factors checked before authenticating the user in.

So the additional factor which gets incorporated here is a simple OTP. Just like we get an OTP while using banking applications, we get an OTP here before logging in. But in this case, OTP is not received by us, it always stays with us and keeps refreshing every 30 sec. This kind of OTP is known as TOPT — Time Based One Time Password. Server will also have the same OTP and keeps refreshing it every 30 sec, as it is time based it is perfectly synced.

If you are interested in knowing how the TOTP is calculated, do refer this — https://devcentral.f5.com/s/articles/two-factor-authentication-with-google-authenticator-and-ldap

As a client, from our end we will use a third party application which can refresh OTPs for us and also be in sync with the Servers OTP. There are many 2FA Authentication apps available both in Play Store and App Store like Google Authenticator, LastPass Authenticator, Authy and many more. In this article we will be using Google Authenticator.

Lets Get Started…

I am going to set this up in an Ubuntu System(20.04). If you use any other Debian based Distro, the installation part works well. But if you use any other Distribution, use the appropriate Package Manager and Package.

Installation —

sudo apt install -y libpam-google-authenticator

Installation of Google Authenticator on Ubuntu 20.04

I have it already installed.

Configuration —

Enter this command on your Linux Machine to start configuring Google Authenticator—

google-authenticator

Configuring Google Authenticator

Enter ‘y’ as we want the tokens to be Time Based and press Enter.

Configuring Google Authenticator

You should see a QR Code now. Ensure you do this in full-screen mode to capture the QR. You have to scan this using your Google Authenticator App.
Install Google Authenticator on your phone. It looks like this —

Google Authenticator on Play Store

After you scan, you should see a Six Digit code in your App which refreshes every 30 sec, it looks similar to this —

Authenticator Sample Code

You can also use the secret key provided to you instead of scanning the QR. You have two options in the app, one — to scan the QR, two — enter the setup/secret key.

Configuring Google Authenticator

Save these details in a safe place and never reveal them to anyone. These will help you recover your Code in case you lose your mobile. With these details anyone can reset the code and sync it with their own device, be careful.

You will be asked few questions while configuring —

Configuring Google Authenticator

I have entered yes to all of them.

The first line saves authenticator file as a hidden file in the user’s home directory.

Second line prevents usage of the Code twice in a 30 sec span, 1 code per login every 30 sec.

Third line provides flexibility with Time Skew which means it not only allows the current code shown in App, but also the previous and next one to ensure you login, despite having any time synchronization issues. Max time configurable is 4 min i.e. 17 codes — 8 previous + current 1 + 8 upcoming.

Fourth line enables Rate Limiting to avoid Brute Force attacks. Max logins permitted is 3 every 30 seconds.

Open ‘/etc/ssh/sshd_config’ in write mode and add the following lines if they don’t exist. If they already exist, modify them like this —

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
UsePAM yes

Editing SSH Config file to support MFA

If you use Password Authentication instead of Public Key, you can comment out ‘AuthenticationMethods publickey,keyboard-interactive’ line.

Save this file and open ‘/etc/pam.d/sshd’ file in write mode now and add the following lines if they don’t exist or modify if they already exist —

#@include common-auth
auth   required   pam_google_authenticator.so

Editing PAM Config file to integrate with Google Authenticator

Save this file and restart SSH Service with this command —

service ssh restart

Now you may exit the user and login again.

After you enter the username, you will be asked for the Verification Code/TOTP.

Logging in to system with MFA enabled

Note: You will not be able to see the Code you are entering as the input type is a secret, just like you cannot see Password entered on a linux system.

Enter the TOTP shown in Google Authenticator for this Login and get into the system.

Some Points to Note —

1. You can use your Secret Key to re-sync the code on a new Phone in case the phone is lost.
2. If you are planning to change your phone, you can always transfer your Google Authenticator data to a new phone.
3. Do not reveal your secret key to anyone.
4. If you are an admin and setting up MFA for all your users, you better have a a secret backup account which has no MFA setup just to ensure in case your account with MFA is compromised, you won’t be able to login.
5. Last but not least, even though we did so much to access Secure Shell Securely, one can still compromise this whole setup if he/she compromises your phone, be aware of this fact.

Conclusion

One should not manage Security of an Organization if he fails to protect his own Phone. Even the most secure environment will have one door open at the least, and it is our fundamental responsibility to protect that as Security Engineers / Security Admins.

Thank you for reading. You can connect with me on Linkedin . Happy to answer your queries.

Good Luck!