How to secure remote server using MFA

How to secure remote server using MFA

If you are working with AWS Public Servers, then one of the main concerns is the security of your public servers

– If your company has VPN configured, then you have a fixed set of IPs that you can whitelist in the Security group of Webserver
– also if you are in the company network, the company may have a list of static IPs with them, which you can whitelist in Security groups

– but If You don’t have VPN, you are not in the company network, you are working from home, then there’s a rare chance that you have a static public IP address which you can whitelist, in this case, every now and then adding new IP of your team’s members can be a cumbersome task that you want to avoid and thus you open all internet traffic to that webserver which is a big security threat

In all the above cases, how do you achieve an extra layer of protection to your servers to prevent them from unauthorised access

Here are some tips that you can follow

1. Configure Strong Password

  • Don’t use “admin”, “user123”, “root” etc. easily hackable passwords, these can be guessed easily and thus unauthorized access possibilities are high
  • Use a strong password with a minimum recommended length of 16 characters, including special characters, numbers, upper case, and lower case letters

2. Make multiple Users

  • Don’t share the same username and password to all the developers, make individual users for all of them, thus only that person has access to his/her password and you can even track which user’s credentials was hacked if something happens
  • Don’t use the same key file/password with all of them, make them create their own password

3. Only give required minimal access

  • Figure out what all minimum access is required for each user and only give minimal access
  • avoid giving admin/root/Sudo permissions if not required

4. Enable MFA on each account

  • Adding Multi-Factor Authentication is an extra layer of security that you must add.
  • Virtual MFA can be added with Google Authenticator [iOS and Android] which can provide you new 6 digit code in addition to password authentication

Let’s see how to configure MFA on your SSH Server (Ubuntu)

  1. SSH into server using root credentials and run the following commands
apt-get update
apt-get install -y libpam-google-authenticator

2. Run the following command to set up MFA on Root user


You will be prompted with the following questions

Do you want authentication tokens to be time-based (y/n)
  • Select yes and press Enter
  • Next, you will be prompted with QR Code and Secret Key
    – Scan QR code using “Google Authenticator” App on your [iOS and Android]
    – Or enter Secret Key in the App using “Enter a Setup Key”

After this, you will also get “Emergency Scratch Code”, Save it at secure and different place then your mobile, If you lost your mobile, these codes can help you login to the system as backup

Next, if you have successfully scanned this code, it will ask you to add this file as below

Do you want me to update your "/root/.google_authenticator" file? (y/n)
  • If you select yes, it will save your all current selections in a file and also will add your secret codes for backup purposes.

    Select yes and press enter
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 option is important because even if someone gets your secret OTP, they won’t be able to log in using the same code after you do.

    So press yes and enter
By default, a new token is generated every 30 seconds by the mobile app.
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. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n)
  • Here, if you are sure that your authentication system has nice synchronization and you want to avoid using old MFA,

    You should go ahead and press no
  • But, if you sometimes need to pass this OTP to other users as well, for debug purposes, time-skew can be an issue

    You should press YES in this case
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
  • Press YES and next, it will implement brute-force protection, thus you can only log in to terminal only 3 times in every 30 seconds

3. Configure SSH to Use Google Authenticator

Now, let’s tell SSH about this google authentication and force it for all user attempts

vi /etc/ssh/sshd_config

Edit following lines in the config

ChallengeResponseAuthentication yes
UsePAM yes
  • Save and Exit

Now, edit PAM config

nano /etc/pam.d/sshd
  • Add below-mentioned line
auth required
  • Save and Close the file
  • Now restart sshd Thread using below mentioned command
systemctl restart sshd

and don’t close the current terminal

4. Now, let’s try and enter into the server using newly set up MFA, in a separate tab

ssh root@IP
// It will prompt for password
// If you enter correct password, it will prompt for Verification Code
// Enter MFA code from Google authenticator app on your phone 

If you are able to login to your system now, Congratulations, you have successfully set up MFA on your Server

We hope you liked this article, share it with your network and share your feedback in comment section below

Drafted On,
22nd January 2022

9 ways to reduce cost of your AWS bill

Leave a Comment