Multi-factor authentication requires more than one factor in order to authenticate, or log in. This article will guide you through the steps to set up multi-factor authentication for SSH on Ubuntu 16.04 server.
Installing Google's PAM
PAM, which stands for Pluggable Authentication Module, is an authentication infrastructure used on Linux systems to authenticate a user. Because Google made an OATH-TOTP app, they also made a PAM that generates TOTPs and is fully compatible with any OATH-TOTP app, like Google Authenticator or Authy.
First, update Ubuntu's repository cache.
sudo apt-get update
installing the PAM by executing the following command
sudo apt-get install libpam-google-authenticator
initialize app with the following command
google-authenticator
You'll be prompted a few questions. The first one asks if authentication tokens should be time-based.
Do you want authentication tokens to be time-based (y/n) y
Note: Make sure you record the secret key, verification code, and the recovery codes in a safe place. The recovery codes are the only way to regain access if you, for example, lose access to your TOTP app.
The remaining questions inform the PAM how to function. We'll go through them one by one.
Do you want me to update your "~/.google_authenticator" file (y/n) y
This writes the key and options to the .google_authenticator file. If you say no, the program quits and nothing is written, which means the authenticator won't work.
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By answering yes here, you are preventing a replay attack by making each code expire immediately after use. This prevents an attacker from capturing a code you just used and logging in with it.
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
Answering yes here allows up to 8 valid codes in a moving four minute window. By answering no, you limit it to 3 valid codes in a 1:30 minute rolling window. Unless you find issues with the 1:30 minute window, answering no is the more secure choice.
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
Rate limiting means a remote attacker can only attempt a certain number of guesses before being blocked. If you haven't previously configured rate limiting directly into SSH, doing so now is a great hardening technique.
Note: Once you finish this setup, if you want to back up your secret key, you can copy the ~/.google-authenticator file to a trusted location. From there, you can deploy it on additional systems or redeploy it after a backup.
Now that Google's PAM is installed and configured, the next step is to configure SSH to use your TOTP key. We'll need to tell SSH about the PAM and then configure SSH to use it.
Configuring OpenSSH
Now, we'll be making SSH changes over SSH, it's important to never close your initial SSH connection. Instead, open a second SSH session to do testing. This is to avoid locking yourself out of your server if there was a mistake in your SSH configuration. Once everything works, then you can safely close any sessions.
sudo nano /etc/pam.d/sshd
Add the following line to the bottom of the file.
/etc/pam.d/sshd
. . .
# Standard Un*x password updating.
@include common-password
auth required pam_google_authenticator.so nullok
The nullok word at the end of the last line tells the PAM that this authentication method is optional. This allows users without a OATH-TOTP token to still log in using their SSH key. Once all users have an OATH-TOTP token, you can remove nullok from this line to make MFA mandatory.
Next, we'll configure SSH to support this kind of authentication. Open the SSH configuration file for editing.
sudo nano /etc/ssh/sshd_config
Look for ChallengeResponseAuthentication and set its value to yes.
/etc/ssh/sshd_config
. . .
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
. . .
Save and close the file, then restart SSH to reload the configuration files. Restarting the sshd service won't close open connections, so you won't risk locking yourself out with this command.
sudo systemctl restart sshd.service
To test that everything's working so far, open another terminal and try logging in over SSH. If you've previously created an SSH key and are using it, you'll notice you didn't have to type in your user's password or the MFA verification code. This is because an SSH key overrides all other authentication options by default. Otherwise, you should have gotten a password and verification code prompt.
Making SSH Aware of MFA
Reopen the sshd configuration file.
sudo nano /etc/ssh/sshd_config
Add the following line at the bottom of the file. This tells SSH which authentication methods are required. This line tells SSH we need a SSH key and either a password or a verification code (or all three).
/etc/ssh/sshd_config
. . .
UsePAM yes
AuthenticationMethods publickey,password publickey,keyboard-interactive
Save and close the file.
Next, open the PAM sshd configuration file again.
sudo nano /etc/pam.d/sshd
Find the line @include common-auth and comment it out by adding a # character as the first character on the line. This tells PAM not to prompt for a password.
/etc/pam.d/sshd
. . .
# Standard Un*x authentication.
#@include common-auth
. . .
Save and close the file, then restart SSH.
sudo systemctl restart sshd.service
Now try logging into the server again with a different session. Unlike last time, SSH should ask for your verification code. Upon entering it, you'll be logged in. Even though you don't see any indication that your SSH key was used, your login attempt used two factors. If you want to verify, you can add -v (for verbose) after the SSH command:
. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammy/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
Authenticated with partial success.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:
Towards the end of the output, you'll see where SSH uses your SSH key and then asks for the verification code. You can now log in over SSH with a SSH key and a one-time password. If you want to enforce all three authentication types, you can follow the next step.
Adding a Third Factor (Optional)
In above step, we listed the approved types of authentication in the sshd_config file:
- publickey (SSH key)
- password publickey (password)
- keyboard-interactive (verification code)
Although we listed three different factors, with the options we've chosen so far, they only allow for an SSH key and the verification code. If you'd like to have all three factors (SSH key, password, and verification code), one quick change will enable all three.
Open the PAM sshd configuration file.
sudo nano /etc/pam.d/sshd
Locate the line you commented out previously, #@include common-auth, and uncomment the line by removing the # character. Save and close the file. Now once again, restart SSH.
sudo systemctl restart sshd.service
By enabling the option @include common-auth, PAM will now prompt for a password in addition the checking for an SSH key and asking for a verification code, which we had working previously. Now we can use something we know (password) and two different types of things we have (SSH key and verification code) over two different channels.
Conclusion
Having two factors (an SSH key + MFA token) across two channels (your computer + your phone), you've made it very difficult for an outside intruder to brute force their way into your machine via SSH and greatly increased the security of your machine.