Using Two Factor Authentication With SSH

The number of data breaches compromising user passwords over recent years has highlighted that relying on passwords alone for authenticating your users isn’t enough if you really want to be secure. The solution to this is called multi-factor authentication (2FA).

The key is to request multiple things from your users to identify them, the three options are:

1 — Something they know, traditionally a password, or personal information question.

2 — Something they have, these tend to be tokens and keys.

3 — Something they are, in this case biometrics like fingerprints or iris scans.

By combining multiple factors, it becomes far more difficult for an attacker to gain unauthorized access to an account. As hardware for making use for the third type, biometrics and fingerprints, is relatively rare, the most commonly used factors are a password with a USB key token or a key generated using a One-time Password algorithm by an application on your computer or phone. Here, we are going to look at how to use app-generated One-Time Passwords to help secure SSH on your server.

Time-based One-Time Passwords, commonly referred to just as OTP, were standardized under RFC 6238, so there are plenty of apps out there supporting it and additionally many websites also work with the codes generated by these apps. Google developed a Linux implementation that they called authenticator, to match with the application of the same name on the Android/iOS app stores. But as it is an implementation of a standard, other OTP apps will work with it.

To get started the first thing you need to do is get the Google Authenticator PAM (pluggable Authentication Module) installed that SSH can use for authentication. On Debian and Ubuntu systems this is easy as the module is in the repositories. For CentOS/Red Hat systems it needs to be installed from source.

Installing on Debian/Ubuntu:

sudo apt-get install libpam-google-authenticator ntp

Installing on CentOS/Red Hat:

sudo yum install make gcc pam-devel ntp

wget https://github.com/google/google-authenticator-libpam/archive/master.zip

gunzip master.zip

./bootstrap.sh

./configure

make

sudo make install

As the One-Time Passwords are time based for their generation you need to ensure the time is accurate on your server, so for that you’ll need to make sure that ntp is installed and enabled:

sudo service ntpd start

sudo chkconfig ntpd on

With the software installed, it’s now time to configure SSH to accept the One-Time Passwords as an authentication method. First we need to edit the config file for SSH’s daemon’s interactions with the PAM:

nano /etc/pam.d/sshd

You’ll need to add the following line to the top of the file on CentOS/Red Hat systems, on Debian/Ubuntu put it after the line that says “@include common-auth”:

auth required pam_google_authenticator.so

Once done, save and exit the file. Next you’ll need to edit the SSH server configuration file to enable challenge-response authentication:

nano /etc/ssh/sshd_config

Find the line that starts with ChallengeResponseAuthentication and set it to yes if it isn’t already, it should look like:

ChallengeResponseAuthentication yes

Finally restart the SSH server to ensure it picks up your changes:

service ssh restart

With this complete, you have now configured the server to ask for a OTP token at login. The only task that remains is to create the tokens for your users. Fortunately, this is quite easy as each user only needs to type the following command:

google-authenticator

This will create and print a QR code on the screen along with a secret key and verification code. Using the Google Authenticator application on your mobile device, or similar OTP app, you can then either scan the QR code or enter the private key on the device to add the code to add it.

Once finished, there are a few questions to answer:

  • The first is whether you want to save the new configuration, this will normally be yes. Secondly, it asks if you want to prevent the reuse of tokens. Generally you’ll want to answer yes to this.
  • Next it asks whether you want tokens to be valid for 1.5 minutes or 4 minutes, and this answer is really up to you.
  • Finally, it asks whether you want to rate limit the amount of token entry attempts that should be made in succession which can prevent brute-force attacks, and generally yes is a good option here too.

With the questions answered and the server’s details added to your authenticator app, it’s now time to try connecting to your server over SSH. We recommend that you make a new connection before closing your existing one just in case something doesn’t go to plan. If all goes well, you should be prompted for your OTP token when logging in. If there are problems, then changing “ChallengeResponseAuthentication” back to “no” in the sshd_config file will remove the request for OTP tokens when logging in. You may need to do this in the short term to allow users to log in while all your users generate their OTP codes.
As you can see, adding a second factor of authentication for your server is simple and can really increase the security of your server. As such it’s something well worth implementing on your systems.

Never miss another post. Sign up for the weekly 100TB newsletter.


Originally published at blog.100tb.com.

Show your support

Clapping shows how much you appreciated 100TB.com’s story.