Linux SSH Hardening: Ed25519 Elliptic Curve Keys, 2FA TOTP & Fail2ban on Pakistani Servers

In the hierarchy of Linux server administration, Secure Shell (SSH) is the master key to your entire digital kingdom. An attacker who gains root terminal access can dump production database tables, alter application binaries, install persistent kernel rootkits, and encrypt filesystems with ransomware.

Yet, hundreds of production servers in Pakistan are still deployed with dangerous, obsolete SSH practices:

• Relying on weak password authentication vulnerable to credential stuffing.
• Using deprecated 1024-bit or 2048-bit RSA keys vulnerable to cryptographic degradation.
• Leaving root login enabled directly on default port 22 without multi-factor authentication.

To establish zero-trust terminal security, modern DevSecOps standards require a three-layered defense: Ed25519 Elliptic Curve Cryptography, Time-Based One-Time Password (TOTP) Multi-Factor Authentication via PAM, and automated behavioral banning via Fail2ban.

This technical guide demonstrates how to execute end-to-end SSH hardening on enterprise Dedicated Servers in Pakistan.

---

Step 1: Why Ed25519 Replaces Legacy RSA Keys

For over two decades, RSA was the undisputed standard for SSH key generation. However, RSA suffers from significant architectural drawbacks:

[Legacy RSA (2048/4096-bit)]
- Large Key Length: Consumes substantial CPU cycles during key exchange
- Vulnerable to Side-Channel Attacks (e.g. cache-timing vulnerabilities)
- Requires at least 3072 bits to meet modern 128-bit security equivalents

[Modern Ed25519 (256-bit)]
- Based on Edwards-curve Digital Signature Algorithm (EdDSA)
- Tiny Key Size: Exactly 256 bits (68 characters)
- Ultra-Fast Signature & Verification (Orders of magnitude faster than RSA)
- Built-in Immunity to Side-Channel and Cache-Timing Exploits

Generating an Ed25519 Key Pair

On your client workstation (Linux, macOS, or Windows PowerShell):

# Generate high-security Ed25519 key with 100 key-derivation rounds
ssh-keygen -t ed25519 -a 100 -C "[email protected]"

Copy the public key to your target production server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

---

Step 2: Enforcing Two-Factor Authentication (2FA) via PAM

Even the strongest SSH private key can be compromised if an administrator’s laptop is infected by an infostealer malware (like RedLine or Lumma). Adding Time-Based One-Time Password (TOTP) 2FA ensures that an attacker cannot log in without the physical 6-digit token from Google Authenticator, Authy, or 1Password.

1. Installing Google Authenticator PAM Module

# On Ubuntu / Debian:
apt-get install -y libpam-google-authenticator

# On AlmaLinux / Rocky Linux:
dnf install -y epel-release
dnf install -y google-authenticator

2. Initializing 2FA for the User

Run the setup wizard as the non-root administrative user:

google-authenticator

Configure the recommended security answers:

• Do you want authentication tokens to be time-based? y
• Do you want to update your .google_authenticator file? y
• Do you want to disallow multiple uses of the same authentication token? y (Prevents replay attacks)
• Do you want to increase the window of acceptable tokens? n (Maintains strict 30-second synchronization)
• Do you want to enable rate-limiting? y (Permits max 3 login attempts per 30 seconds)

Scan the generated QR code using your mobile authenticator app and save your 5 emergency scratch codes in an offline safe.

---

Step 3: Hardening the OpenSSH Server Daemon (/etc/ssh/sshd_config)

To enforce Ed25519 keys and 2FA while permanently disabling password authentication, edit /etc/ssh/sshd_config:

# /etc/ssh/sshd_config

# 1. Custom High Port (Defeats 99% of generic automated internet port scanners)
Port 2222

# 2. Network Protocols & Address Binding
Protocol 2
AddressFamily inet

# 3. Disable Root Login Completely (Force login via non-root sudoer)
PermitRootLogin no

# 4. Enforce Public Key Authentication
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# 5. STRICTLY Disable Password & Blank Passwords
PasswordAuthentication no
PermitEmptyPasswords no

# 6. Configure Two-Factor Authentication (Public Key + PAM TOTP)
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes

# Require BOTH a valid SSH Key AND a valid 2FA TOTP code!
AuthenticationMethods publickey,keyboard-interactive

# 7. Modern Cryptographic Ciphers & MACs (Disable SHA-1 and 3DES)
KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected]
MACs [email protected]

# 8. Session Timeouts (Auto-disconnect idle sessions after 10 minutes)
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3

Configure PAM for SSH (/etc/pam.d/sshd)

Ensure PAM requests the TOTP token:

# Add to the very top of /etc/pam.d/sshd:
auth required pam_google_authenticator.so nullok

(The nullok flag allows existing users without 2FA configured to log in during initial onboarding; remove nullok once all engineers have configured their tokens).

Test syntax before restarting:

sshd -t
systemctl restart sshd

---

Step 4: Automated Behavioral Banning with Fail2ban

To catch rogue scanners hammering your custom SSH port, deploy Fail2ban. Fail2ban inspects auth logs and dynamically updates kernel firewall tables:

# Install Fail2ban
apt-get install -y fail2ban || dnf install -y fail2ban

Create /etc/fail2ban/jail.local:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 86400        # Ban offending IP for 24 hours
findtime = 600          # Look back over 10 minutes
maxretry = 3            # Ban after 3 failed attempts
banaction = iptables-multiport

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s
backend = systemd

Restart Fail2ban:

systemctl restart fail2ban
fail2ban-client status sshd

---

The Result: An Impenetrable Access Gateway

When an administrator connects:

ssh -p 2222 [email protected]
# 1. Client automatically authenticates via local Ed25519 private key
# 2. Server prompts: "Verification code: " -> Enter 6-digit TOTP from phone
# 3. Successful secure login!

If an attacker steals your private key, they cannot authenticate without your phone. If they attempt to guess credentials, Fail2ban blacklists their IP address for 24 hours after 3 attempts.

For corporate platforms managing high-value financial data, hosting terminal gateways on isolated bare-metal servers provides guaranteed physical security, unshared network hardware, and dedicated IPMI out-of-band disaster recovery.

Explore Nextgen’s high-performance bare-metal Dedicated Servers and locally hosted Dedicated Servers in Pakistan.