Securing SSH (Port 22) with Multi-Factor Authentication (MFA)

This article explains how to secure SSH (Port 22) with Multi-Factor Authentication (MFA), enhancing the security of remote access and preventing brute-force attacks.

Technology News Dec 22, 2024 1 69 Add to Reading List

Securing SSH (Port 22) with Multi-Factor Authentication (MFA)

SSH (Secure Shell) access is one of the most important methods for managing remote servers, but leaving Port 22 open to the internet can make your servers vulnerable to brute-force attacks. Fortunately, by implementing Multi-Factor Authentication (MFA), you can significantly enhance the security of your SSH login process.

In this guide, I’ll show you how to secure your SSH access by adding an extra layer of protection using Google Authenticator and Time-based One-Time Passwords (TOTP). These steps will ensure that even if your private SSH key is compromised, unauthorized access to your server will remain highly unlikely.

Why Use MFA for SSH?

Extra Layer of Protection: MFA adds a second form of authentication (a dynamic OTP from your phone) to the SSH login process. Even if your SSH key is stolen, attackers still need the OTP.
Brute-Force Attack Protection: MFA makes brute-force attacks ineffective because attackers can't simply guess your SSH credentials—they also need access to your authenticator app.
Improved Security: MFA combines something you know (SSH key) with something you have (an authenticator app), creating stronger protection for your server.

Steps to Secure SSH with MFA:

Step 1: Install Google Authenticator PAM Module

The first step is to install the Google Authenticator PAM (Pluggable Authentication Module) on your server, which will enable the TOTP functionality.

Commands for installation:

Install the PAM module:

For Debian/Ubuntu systems:

Commands:-

sudo apt-get update
sudo apt-get install libpam-google-authenticator

For CentOS/RHEL systems:

Command:- sudo yum install google-authenticator

Install Google Authenticator app: On your phone, install the Google Authenticator app (available on both Android and iOS) or use any TOTP-compatible authenticator app like Authy.

Step 2: Configure Google Authenticator for Each User

After installing the PAM module, you'll need to configure Google Authenticator for the user accounts that require MFA.

Commands for user setup:

Run Google Authenticator for the user account:

Commands:- google-authenticator

This command will prompt you with several questions. Here’s a breakdown of the important steps:
- Do you want to update your "/home/user/.google_authenticator" file?
  - Answer yes to generate a configuration file.
- Do you want me to disallow multiple uses of the same authentication token?
  - Answer yes for better security.
- Do you want to enable rate-limiting?
  - Answer yes to prevent brute-force attacks.
After answering these questions, Google Authenticator will generate a QR code. Use your Google Authenticator app (or another TOTP app) to scan this QR code. This will sync your phone with your server for TOTP generation.
The app will generate a unique, time-based code every 30 seconds that will be used during the SSH login.

Step 3: Configure PAM for MFA

Next, modify the PAM configuration file for SSH to enforce MFA.

Edit the PAM SSH configuration:

Commands:- sudo nano /etc/pam.d/sshd

Add the following line to the file (ensure it’s added towards the end of the file):

Commands:- auth required pam_google_authenticator.so

This line ensures that Google Authenticator’s MFA is required for SSH logins.

Step 4: Update SSH Configuration

Now that the PAM configuration is complete, you need to update the SSH daemon settings to allow for MFA.

Edit the SSH configuration file:

Make sure the following settings are configured:

PubkeyAuthentication yes: Allows SSH key authentication.
PasswordAuthentication no: Disables password-based login to enforce public key + MFA authentication.
ChallengeResponseAuthentication yes: Enables the MFA step during SSH login.

Save and exit the file.

Step 5: Restart SSH Daemon

After updating the configurations, restart the SSH service for the changes to take effect.

Commands:- sudo systemctl restart

Step 6: Test the MFA Setup

Now, it’s time to test your MFA configuration:

Log in via SSH to your server using your private SSH key:

The system will prompt you for two pieces of information:
- Your SSH private key passphrase (if it’s set).
- The TOTP code from your Google Authenticator app.
Enter both to complete the login process. If both are correct, you’ll be granted access to your server.

Additional Security Tips for SSH

While MFA greatly enhances SSH security, here are a few additional best practices to further protect your server:

Limit SSH Access by IP: Restrict SSH access to specific IP addresses by modifying firewall rules or using the AllowUsers directive in the sshd_config file.

Commands:- AllowUsers username@trusted_ip

Use Strong SSH Key Passphrases: Protect your private SSH key with a strong passphrase to add another layer of security.
Enable Fail2Ban: This tool helps block IP addresses that show signs of malicious activity, such as repeated failed login attempts.
Regularly Monitor Logs: Keep an eye on /var/log/auth.log for any failed login attempts or suspicious activity.
Backup Your Authenticator Codes: In case you lose access to your phone, make sure you have a backup method to regain access. Most authenticator apps offer a way to export or back up your keys.

Conclusion:

By following these steps, you’ve successfully implemented Multi-Factor Authentication (MFA) for SSH access. This extra layer of security ensures that even if an attacker compromises your SSH key, they still can’t access your server without the dynamic, time-based one-time password (TOTP) generated by your authenticator app.

In a world where security threats are becoming more sophisticated, securing SSH with MFA is a must-do practice for anyone managing critical infrastructure. It’s a small effort with a huge payoff in terms of security.

Discussion:

Have you implemented MFA for your SSH access? What challenges did you face, or did you use a different method for securing your SSH login? Feel free to share your thoughts or ask any questions below!