How to setup 2 factor Authentication for SSH on Ubuntu

Go360host.com > Knowledgebase > General > How to setup 2 factor Authentication for SSH on Ubuntu

Overview

Securing SSH is a difficult topic. It’s generally recommended to use SSH keys, and disable password authentication to prevent automatic brute force attacks from discovering your password. If you want to use SSH keys you can use this guide to set them up before proceeding.

However, this isn’t always possible. You may wish to access your server via SSH from a mobile app which doesn’t support public key authentication. Even if you do have SSH keys in use, the most common practice of using encrypted private keys (no password has to be entered to use them) means any attacker with access to your computer now has access to all your servers too!

What is 2 Factor Authentication?

Using 2 factor authentication can help to avoid this risk, by making another device necessary to connect. It could be a mobile device or a dedicated piece of hardware. These generate time-limited codes which help to ensure that only you have access to the SSH, even if someone else has access to your computer.

Setting up 2 factor authentication for the additional peace of mind it offers is a relatively quick and easy task.

2 Factor Authentication Clients

Mobile

These apps exist on the major mobile app stores. Simply choose the one for you and download it.

With these, you can scan a QR code generated by your server to import the key, and allow the app to generate codes.

Hardware

Another option instead of using a mobile app is with a dedicated piece of hardware. The YubiKey and Yubikey Nano are two examples of the many hardware devices that exist to generate 2 factor authentication codes.

In theory, by eliminating an internet connected storage device, these ensure greater security. Many also identify themselves to the host computer as a USB keyboard, ensuring high levels of compatibility. There is, however, a downside. The time-based one time passwords used by most common 2-factor-authentication systems often require a “helper application” to be installed on the host computer. The compatibility may vary based upon what hardware you purchase, so it’s worth checking before buying.
The easiest of the hardware key devices are when they support importing a secret key. If this feature is present, it will most likely be detailed in the product specifications.

Securing SSH with 2 factor authentication

Please note: If you install and setup 2 factor authentication for a user other than root, you won’t be able to log in as root unless you also configure the system for root. Additionally, if you’re using encrypted home directories, this will fail as the public keys are stored in encrypted directories, and hence cannot be accessed to verify your code.

To begin, you should log into your vps as root, or log in as a non-root user and switch to root with the following command.
sudo su -
Installation

Once this is complete, you need to install the package libpam-google-authenticator with this command.
apt-get install libpam-google-authenticator nano -y
Configuration And Setup

This package requires a few configuration changes to activate it.

First ,we need to edit /etc/ssh/sshd_config to enable challenge/response authentication.

Open up the file for editing
nano /etc/ssh/sshd_config
You now need to find the line that says ChallengeResponseAuthentication no. To search for this, press “control-W” and enter ChallengeResponseAuthentication no, then press enter.

Change this line to say ChallengeResponseAuthentication yes then save the file and exit via Control-O and Control-X.
We now need to prepend the line auth required pam_google_authenticator.so to the start of the file/etc/pam.d/sshd

Open the file for editing:
nano /etc/pam.d/sshd
Now paste auth required pam_google_authenticator.so on the first line, and press Control-O and Control-X to save and exit.

If you’re using SSH keys,you will need to comment out the line that says
@include common-auth
By changing it to be
#@include common-auth
Please note that this disallows password authentication, so you can only use this for keys and 2 factor. If you’re using passwords and 2 factor, you don’t need to worry about commenting out this line.

Once done you can close and save the file using Control-O and Control-X again.

Next we will append the line
AuthenticationMethods publickey,keyboard-interactive
to /etc/ssh/sshd_config by running the following command.
echo AuthenticationMethods publickey,keyboard-interactive >> /etc/ssh/sshd_config
Enabling For User

You now need to switch to the user who you intend to activate the 2 factor authentication for, and run the following command:
google-authenticator
You will be asked a series of questions.
Do you want authentication tokens to be time-based (y/n) .
You should answer this with y unless you’re using a hardware key device which doesn’t support time based keys.

You will then be presented with something similar to the image above.

You scan this code in the 2 factor authentication app on your phone, and make a paper record of the emergency codes, in case you lose your mobile device. If you’re using a hardware code generation device, you will need to import this secret key according to the manufacturer’s instructions.

Once done, another group of questions will be asked.
Do you want me to update your "/root/.google_authenticator" file (y/n)
You should answer with y.
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)
This can typically be answered with ‘y’ as it is very unlikely that you will need to log in more than once per 30 seconds.
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)
Generally this can be set to y, although it depends upon the timekeeping of your phone/device and your server.
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)
It is typically a good idea to set this to y, especially if you don’t have rate limiting software like fail2ban installed.

Now you should restart the SSH service to apply our changes with the following command:
service ssh restart
Testing

Leave your existing SSH session open until you’ve verified that you can log in successfully via ssh after making the changes.

Open another window in your terminal/ssh program, and connect, entering the key generated by your app when prompted.

If this works, you should be ready to go!

Sometimes, you might experience errors logging in at this stage, and you may need to check the file/var/log/auth.log for debugging information in the event of any issues. If you’re not sure what’s going on, it’s best to disable the 2 factor authentication until you can get a definite solution, or you’ll risk being unable to access your server.

Disable 2 Factor

If for whatever reason you need to disable 2 factor authentication you can do it by editing these two files.
nano /etc/pam.d/sshd
Comment out the line
auth required pam_google_authenticator.so
You can do this by adding a #at the start of the l i n e . If you commented out the line @include common-auth earlier,you will need to remove the # . Next
nano /etc/ssh/sshd_config
Change the line that says
ChallengeResponseAuthentication yes
to
Challenge Response Authentication no
Also remove the line that says
Authentication Methods publickey,keyboard-interactive
If you added it earlier. Now restart ssh and it should disable the changes we made earlier:
service ssh restart
Conclusion

A relatively simple setup procedure that is easily accomplished in under 15 minutes can give you a great deal more peace of mind for your server security. Properly securing your server is a vital step in administering your server and this is just one of the many things you should be doing to protect yourself.