RECOMMENDED: Click here to fix Windows errors and optimize system performance
When users access your unmanaged VPS, cloud VPS or Flex dedicated server via SSH, they enter a username and password to log in by default.
Two-factor authentication provides an additional level of security by requiring users to provide additional information in addition to knowing the correct username and password. This information is a temporary digital password that is generated independently on the server and on a mobile device, such as a smartphone or tablet.
Therefore, in order for a potential attacker to access your server, he would have to obtain not only something you know (your username and password), but also something you have (your mobile device). This two-factor approach to logging in greatly increases the security of your server and makes brute force attacks much more difficult.
How to Enable Two Factor for SSH
To process two-factor requests, we use Google’s Plug-in Authentication Module (PAM), which works with Authy and Google Authenticator. Install it via your distribution’s package manager:
sudo apt-get install libpam-google-authenticator
Then execute this initialization command:
Answer the first question if the authentication tokens should be time-based by yes. This is more secure. Your terminal will then be flooded with a gigantic QR code, and you’ll probably have to zoom out slightly.
Open your authentication application and scan your code (not the screenshot). Your application should synchronize and start generating six-digit codes that change every 30 seconds.
You should also note any additional exits, including the secret key and emergency scratch codes. These are used to regain access to your server if you are blocked for any reason. However, you should be warned that if you encounter problems due to a bad configuration, you can always be permanently banned. Before making the test mandatory, we have the possibility to activate two factors.
For the next questions, please answer the following questions:
- Answer “Yes” to the question about updating your configuration, otherwise nothing will work.
- Answer “Yes” to the question whether multiple use of different tokens is not allowed. They must expire as soon as they are used.
- Answer the question about extending the valid code window in the negative, because it doesn’t actually make any sense.
- Answer “yes” to allow a rate limit that excludes attackers after three attempts. Your last three codes are valid for a minute and a half, so you don’t have to worry about locking yourself in by acting too slowly.
Your entire configuration is stored under ~/.google-authenticator. You can copy this file to an additional server to apply the same configuration; do not run the initialization tool again, or you will have to connect two separate devices.
Since we are going to make changes from SSH to SSH, it is important to never close your initial SSH connection. Instead, open a second SSH session for testing. This way, you will avoid locking yourself to your server if an error occurred in your SSH configuration. Once everything is working, you can safely close all sessions.
To get started, open the sshd configuration file to edit it with nano or your favorite text editor.
sudo nano /etc/pam.d/sshd
Add the following line at the end of the file.
auth required pam_google_authenticator.so nullok
The word Nullok at the end of the last line indicates to MAP that this authentication method is optional. This allows users without an OATH-TOTP token to log in anyway with their SSH key. Once all users have an OATH-TOTP token, you can remove the word nullok from this line to make AMF mandatory.
Save and close the file.
Next, we will configure SSH to support this type of authentication. Open the SSH configuration file to edit it.
sudo nano /etc/ssh/sshd_config
Find ChallengeResponseAuthentication and set the value to yes.
Save and close the file, then restart SSH to reload the configuration files. Restarting the sshd service will not close any open connections, so you won’t get stuck with this command.
sudo systemctl restart sshd.service
To test if everything works so far, open another terminal and try to connect via SSH. If you have already created an SSH key and are using it, you will notice that you have not had to enter your user password or the AMF verification code. Indeed, an SSH key overrides all other authentication options by default. Otherwise, you should have received a message inviting you to enter your password and verification code.
Then, to allow an SSH key to be one factor and the verification code to be a second factor, we need to tell SSH which factors to use and prevent the SSH key from overriding all other types.
RECOMMENDED: Click here to troubleshoot Windows errors and optimize system performance
CCNA, Web Developer, PC Troubleshooter
I am a computer enthusiast and a practicing IT Professional. I have years of experience behind me in computer programming, hardware troubleshooting and repair. I specialise in Web Development and Database Design. I also have a CCNA certification for Network Design and Troubleshooting.