Sometimes, you want to be doubly sure that no one can get access to your VPS but you. If two-factor authentication (2FA) can work for our dashboards, why not for logging into a VPS?
In this tutorial, we’ll talk about adding 2FA to SSH logins on a VPS running Ubuntu 16.04 using Google Authenticator. This will add another layer of protection for SSH logins, and can be used either in conjunction with password-based logins, or with the SSH keys you might already use.
Some people would argue that using SSH keys make 2FA obsolete, and that might be true in certain applications, but we think users should know about all the options available to them before choosing any one security strategy.
Prerequisites
- A VPS running Ubuntu 16.04
- A non-root account that you can SSH into
Step 1. Installing Google Authenticator on the VPS
First off, you need to install the Google Authenticator program and run it as the user you’re going to log in with—preferably not the root account.
$ sudo apt-get install libpam-google-authenticator
$ google-authenticator
You’ll first be prompted as to whether or not you want to use time-based tokens. The other option is one-time tokens, which is probably not what you want. Type in y to use time-based tokens.
Do you want authentication tokens to be time-based (y/n) y
Once you confirm time-based tokens, you’ll see a large amount of output on your terminal. This will include the QR code that you can use with Google Authenticator (or another similar program), or a secret key that you can enter in manually if your device can’t scan QR codes. Lastly, there are
Once you’ve set up the token on your mobile device, you can take a look at the secret keys that the program generates, along with emergency scratch codes, which you can use once if you lose that device.
There are a few more questions to answer—the first of which is whether you want to save the authenticator settings. Answer in the affirmative.
Do you want me to update your "/home/USER/.google_authenticator" file (y/n) y
The next option helps reduce the risk of certain attacks, so you’ll want to use it as well.
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
The next option, to help reduce the effects of time-skew, probably isn’t necessary. If you do have problems later on, you can re-run this configuration and select y instead.
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
The last option allows you to set a limit on how many times someone can attempt to use security tokens—no more than 3 times every thirty seconds. This dramatically reduces the risk of brute force attacks.
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
Step 2. Enable Google Authenticator in SSH
Before we go any further, it’s best to work in multiple SSH connections in multiple terminals beyond this point. If you try this using only a single terminal, you might misconfigure SSH and lock yourself out of your VPS. By keeping one SSH connection active and using a second terminal to test these new settings, you can always make further tweaks or roll back to a setting that works.
In order to enable using these codes via SSH, you need to edit the /etc/pam.d/sshd file and add the following line in at the beginning.
auth required pam_google_authenticator.so
You’ll then need to open /etc/ssh/sshd_config and look for the ChallengeResponseAuthentication line. If you have one, you can simply change no to yes, and uncomment it (remove the #) if
necessary.
The line should look like this:
ChallengeResponseAuthentication yes
Finally, you just need to restart SSH.
$ sudo systemctl restart sshd
At this point, you can try connecting to your VPS. You’ll first be asked for your password, followed by the verification code, followed by your password. If all is working well, you’ll be logged in!
Final thoughts
As I mentioned before, SSH keys are often a superior option over 2FA when it comes to dealing with servers on a regular basis, but there are likely certain configurations where 2FA makes a lot of sense.
In fact, the two can be combined together, for those who want multiple factors on entirely different devices, plus passphrases (if their SSH keys use them). To do that, all you have to do is comment out the auth required pam_google_authenticator.so line in your /etc/pam.d/sshd, and then add in the following at the top of the same file: auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok.
And, finally, don’t be like me—make sure your Num Lock is on before you drive yourself crazy trying to figure out why the verification codes don’t work.
