Hardening Your SSH Server: Beyond Password Authentication

SSH is the front door to your Linux server — and on many systems, it’s wide open by default.

Out‑of‑the‑box SSH configurations prioritize convenience over security:

• Password authentication is enabled
• Root login may be allowed
• No protection against brute‑force attacks
• Weak or outdated cryptography settings

This article walks through practical, real-world SSH hardening techniques that dramatically reduce your attack surface without sacrificing usability.

You’ll learn how to:

• Replace passwords with SSH keys
• Harden sshd_config safely
• Protect SSH with fail2ban
• Use port knocking for stealth access
• Validate your setup without locking yourself out

Why SSH Is a Primary Attack Target

Internet-facing servers are constantly scanned for open SSH ports. Attackers rely on:

• Default ports (22)
• Password guessing
• Common usernames (root, admin, user)
• Weak SSH configurations

📊 On exposed servers, thousands of login attempts per day are common.

📷 World map showing global SSH brute-force attempts

Step 1: Switch to SSH Key-Based Authentication

Passwords are vulnerable to brute-force and credential reuse attacks. SSH keys are not.

How SSH keys work (briefly)

• You generate a private key (kept secret)
• A public key lives on the server
• Authentication uses cryptography instead of passwords

📷 Diagram :

SSH key authentication flow

Generate an SSH Key (Client Side)

Shell

ssh-keygen -t ed25519 -

✅ Press Enter to accept defaults

✅ Use a passphrase for extra security

This creates:

• ~/.ssh/id_ed25519 (private key)
• ~/.ssh/id_ed25519.pub (public key)

Install the Public Key on the Server

Shell

ssh-copy-id user@server_ip

Test login before proceeding:

Shell

ssh user@server_ip

Show more lines

📺 Video tutorial:

“SSH Key Authentication Explained”

https://www.youtube.com/watch?v=0fMqVx7DhcI

Step 2: Harden sshd_config (Safely)

The SSH daemon configuration file is located at:

Shell

/etc/ssh/sshd_config

⚠️ Always keep an active SSH session open when editing this file.

Recommended Secure Settings

Apache Config

Protocol 2
Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers yourusername

What These Do

SettingPurposePermitRootLogin noPrevents direct root accessPasswordAuthentication noForces key-based loginMaxAuthTries 3Limits brute-force chanceAllowUsersRestricts SSH access

Test and Reload SSH

✅ Check config syntax first

Shell

sudo sshd -t

✅ Reload safely

Shell

sudo systemctl reload sshd

📺 Video overview:

“Secure SSH Configuration Explained”

https://www.youtube.com/watch?v=ZSYnEXsr8pM

Step 3: Add Brute-Force Protection with fail2ban

Even with keys, fail2ban protects against enumeration, DoS attempts, and misconfigurations.

Install fail2ban

Shell

sudo apt install fail2ban
# or
sudo dnf install fail2ban

Enable SSH Protection

Create a local jail file:

Shell

sudo nano /etc/fail2ban/jail.local

<jail.local file>

[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 1h
findtime = 10m

Start the service:

Shell

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

✅ View banned IPs:

Shell

sudo fail2ban-client status sshd

📺 Video tutorial:

“fail2ban Setup SSH Protection”

https://www.youtube.com/watch?v=HfMEfx_yTeQ

Step 4: Optional – Change the SSH Port (Security by Obscurity)

Changing the port does not replace proper security, but it reduces noise from automated scans.

Apache Config

Port 2222

Update your firewall accordingly (nftables example):

Shell

sudo nft add rule inet filter

Next, test from another terminal:

Shell

ssh -p 2222 user@hostname

Step 5: Port Knocking (Advanced but Powerful)

Port knocking keeps SSH entirely hidden until a secret knock sequence is sent.

How it works

1. SSH port remains closed
2. A sequence of connection attempts opens the port
3. Access closes automatically

📷 Diagram:

Port knocking workflow

Tools

• knockd
• firewall (nftables/iptables)

📺 Video demonstration:

“Port Knocking Explained”

https://www.youtube.com/watch?v=Xd5xM8Gk9hw

⚠️ Best suited for admins with solid firewall knowledge.

Step 6: Lock SSH to Specific IPs (Best Practice)

If you connect from fixed locations, restrict SSH access.

Apache Config

AllowUsers youruser@192.168.1.0/24

Or with nftables:

Shell

sudo nft add rule inet filter input ip saddr 203.0.113.10 tcp dport 22 accept

Common SSH Hardening Mistakes

❌ Disabling password auth before testing keys

✅ Always test key login first

❌ Editing SSH over a single session

✅ Keep a backup terminal open

❌ Forgetting firewall rules

✅ SSH can break silently

Final Thoughts

SSH hardening doesn’t require exotic tools — just layered, intentional security.

At a minimum, every Linux server should use: ✅ SSH keys

✅ Root login disabled

✅ Password auth disabled

✅ Brute-force protection

Take it further with port restrictions and stealth techniques as your threat model grows.