DEV Community: Rupesh Sharma

Transform Your Linux Security: Activate MFA for SSH with Google Authenticator for Unbreakable Protection

Rupesh Sharma — Mon, 27 Jan 2025 07:32:46 +0000

Introduction

Enforcing MFA (Multi-Factor Authentication) on a Linux system for authenticating is important for enhancing security. This blog will guide you to set up MFA for your Linux system by providing secure SSH(Secure Shell) connection.

Prerequisites for this setup

A Linux system
Google-Authenticator App on smartphone.
openssh ( If you don’t have openSSH, install using sudo apt install openssh-server)

Now the we know the prerequisites to enable MFA on linux, let’s dive into the steps configre it.

Step 1: Update and Install Google-Authenticator

sudo apt update -y

sudo apt install libpam-google-authenticator

Step 2: Configure Google Authenticator for Users

google-authenticator

After you execute the above command, you a QR code will be generated, upon scanning it will redirect you to your Google Authenticator app to save key for the user you are logged into. Make sure you have logged in to your Google Authenticator in Phone. You will be asked to enter the code from your google authenticator.

You will be asked to configure the Authenticator with following Questions;
_

Do you want authentication tokens to be time-based (y/n) _ If you choose “y”: OTPs will be time-based, changing every 30 seconds, ensuring higher security.

If you choose “n”: OTPs won’t be time-based, which can lower security as the token remains valid longer.

Recommended : yes
_

Do you want me to update your “/home/vagrant/.google_authenticator” file? (y/n)_

If you choose “y”: The .google_authenticator file will be updated with the secret key, enabling Google Authenticator to work properly.

If you choose “n”: The .google_authenticator file won’t be updated, and the changes will not take effec

Recommended : yes
_

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)_

If you choose “y”: OTPs can only be used once, preventing attackers from reusing the same token in multiple login attempts.

If you choose “n”: OTPs can be reused, which may increase the risk of successful brute-force attacks or replay attacks.

Recommended : yes
_

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 minutesbetween client and server.

Do you want to do so? (y/n)_

If you choose “y”: A larger time window for OTP validation will be allowed (up to 4 minutes) to account for time differences between the client and server.

If you choose “n”: The default 30-second window for OTP validation will be used, which is more secure but requires precise time synchronization.

Recommended : no

5. 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)

If you choose “y”: Rate-limiting will be enabled, restricting attackers to 3 login attempts every 30 seconds, slowing down brute-force attacks.

If you choose “n”: No rate-limiting will be applied, making the system more vulnerable to brute-force login attempts.

Recommended : yes

In short, For security, it’s recommended to choose “y” for time-based authentication, updating the file, disallowing token reuse, and enabling rate-limiting, and “n” for 4th Question.

Step 3:Integrate Google Authenticator with PAM

Edit PAM configuration and add given line at the top of the pam config file: auth required pam_google_authenticator.so

sudo nano /etc/pam.d/sshd

Step 4: Configure SSH config file

Edit the /etc/sshd/sshd_config and add the given lines if they already exits just type “yes” to enable it.

ChallengeResponseAuthentication yes

KbdInteractiveAuthentication yes

Restarting the sshd service to reload new configuration

Step 5: Verifying the implementation of MFA on Linux server.

Now when you ssh into Linux Server you have to enter the verification code from Google-Authenticator App on your Phone. And then when you enter the correct password for the user you are logging in, you get the access to the Linux server.

The Attack that can be prevented using MFA for SSH

Brute Force Attacks: Rate-limiting restricts login attempts, making it difficult for attackers to guess SSH passwords.
Credential Stuffing: MFA ensures that even if an attacker obtains SSH credentials, they can’t access the system without the second factor.
Man-in-the-Middle (MITM) Attacks: Time-based OTPs prevent attackers from intercepting and replaying SSH authentication tokens.
Replay Attacks: Disallowing token reuse ensures that intercepted SSH tokens can’t be reused for subsequent logins.
Password Guessing: MFA adds an additional layer of security, making it harder for attackers to access the system through SSH.
Phishing Attacks: Even if SSH login credentials are phished, the attacker still requires the OTP to successfully authenticate.

Conclusion

Securing SSH access is crucial for protecting your Linux systems from cyberattacks. By enabling MFA with Google Authenticator, you add an extra layer of security that safeguards against brute force, phishing, and other unauthorized access attempts. With this easy-to-follow guide, you can significantly enhance your system’s protection and stay ahead of potential threats. Prioritize your Linux security today and make your SSH connections safer than ever!

Master File Transfers and Backups with Rsync and SCP: A Beginner’s Guide

Rupesh Sharma — Mon, 27 Jan 2025 07:19:04 +0000

Introduction

Managing file transfer and backups are en essential skill everyone should must learn. Two most popular tools for this purpose are scp and rsync. While scp is simple to securely send or receive file to and from remote server to local server, rsync is popular for data backup, data synchronization and server mirroring. This blog will help you understand how to get started with both the tools and choose which one to use wisely.

1. rsync:
rsync is a fast and flexible tool to copy and synchronize files and directories, either locally or between systems. It is commonly used for backups, mirroring, and transferring data efficiently.

2. SCP (Secure Copy Protocol):
A simple tool for securely copying files between systems over SSH. It encrypts data during transit, ensuring security. Best for quick, straightforward file transfers.

When to Use

Rsync:
For syncing large datasets efficiently.
When saving bandwidth is important.
To mirror directories with file attributes preserved.

SCP:
For secure, quick file transfers.
When simplicity is more important than advanced features.
For smaller or occasional transfers.

Installing rsync

rsync is by default installed on Linux system, in case rsync is not available try installing using:

sudo apt install rsync

Most useful rsync option:

-a : Archive Mode for recursive copying, preserving permissions,timestamps, and other attributes
-v : Verbose Mode, shows details of what happening
-z : Compress Mode, allows to compress the file during transfer to save the bandwidth.
-h : Makes numbers easier to read (e.g., file sizes in KB, MB)
-P : Displays the progress of the file transfer.
-r : Recursively copies files and directories, but doesn’t preserve timestamps or permissions.
--dry-run : Allow user to simulate the rsync transfer without copying or syncing the files.

Note: You will need to have the username ,password and IP address of the remove server where you want to sync,copy or mirror your files using rsync and scp.

Rsync for file Transfer

Local Transfer

Remote Transfer

Remote Synchronization

Using --backup-dir for enhanced backup system:

This option will allow the user to back up the file and also keep the record of previous version of the file for effective backup system.

On the remote backup-server it can be seen that there are two file recorded, on /Archive folder a back-file.txt is create which hold the previous version of the backup-file. On the other hand, there is also a recent backupfile updated with recent changes.

Converting the command into simple backup script.

This is the simple script to backup file with rsync.


#!/bin/bash
#@Author: Rupesh Sharma

SOURCE_FILE="/home/vagrant/backup/backup-file.txt"
BACKUP_SERVER="vagrant@192.168.56.20:/home/vagrant/rsync"
ARCHIVE_DIR="/home/vagrant/rsync/Archive"
DATE_TIME=$(date +%Y-%m-%d-%H:%M:%S)
rsync -vazh --backup-dir="$ARCHIVE_DIR/$DATE_TIME" "$SOURCE_FILE" "$BACKUP_SERVER"

echo "Backup Completed for : $DATE_TIME

SCP(Secure Copy Protocol)

Similar to rsync SCP is by default installed on Linux system, in case SCP is not available try installing using:

sudo apt install openssh-client

Transferring file to Remote server

Transferring file using scp for local system to remote system.
verifying the file transferred from local to remote system.

Pulling file from Remote server to local server using local server. Pulling file from Remote server to local server using local server

Conclusion

To conclude with, both rsync and scp are indispensable tools for file transfer and synchronization. While scp is ideal for simple, secure transfers, rsync excels in efficiency, making it perfect for backups and large-scale synchronizations.