How To Setup 2 Factor Authentication For SSH On Ubuntu

2 factor

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.

app store

 

 

play store

 

 

windows store

 

 

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. If you are not sure how to SSH into your server you can look at our SSH guide: HERE

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 C​hallengeResponseAuthentication no.​ To search for this, press “control-W” and enter C​hallengeResponseAuthentication no​, then press enter.

Change this line to say C​hallengeResponseAuthentication yes then save the file and exit via Control-O and Control-X.

We now need to prepend the line a​uth required pam_google_authenticator.so t​o the start of the file /etc/pam.d/sshd

Open the file for editing:

nano /etc/pam.d/sshd

Now paste a​uth 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

P​lease 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

A​uthenticationMethods publickey,keyboard-interactive

t​o /etc/ssh/sshd_config b​y 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) .​

Y​ou should answer this with y​​ unless you’re using a hardware key device which doesn’t support time based keys.

2 factor results

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

a​uth 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

 

n​ano /etc/ssh/sshd_config

Change the line that says

C​hallengeResponseAuthentication yes​

to

Challenge Response Authentication no

Also remove the line that says

A​uthentication 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.

CC BY 4.0 This work is licensed under a Creative Commons Attribution 4.0 International License.

Thomas Wemyss has written 1 article

I am a keen programmer with a particular interest in parallel and distributed computing, and their application in scientific research

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>