Secure SSH on Debian 13 with Key Authentication and Fail2ban

SSH is one of the first services attackers look for when scanning servers across the internet. If your Debian 13 server still allows password logins, it is only a matter of time before automated bots start attempting thousands of login combinations.

The good news is that securing SSH does not require complicated security tools. By switching to SSH keys and adding Fail2ban, you can dramatically reduce the risk of unauthorized access.

In this guide, we'll secure SSH on Debian 13 using:

SSH key authentication
Root login protection
Password login disablement
Fail2ban brute force protection

By the end, your server will be far better protected against common attacks.

Prerequisites

Before starting, make sure you have:

A Debian 13 dedicated server
Root or sudo access
SSH access to the server
A local computer running Linux, macOS, or Windows

Step 1: Update Your Debian 13 Server

Start by updating the package repository and installed packages.

sudo apt update
sudo apt upgrade -y

Keeping packages updated is one of the simplest ways to reduce security risks.

Step 2: Verify OpenSSH Server Is Installed

Check whether the SSH service is already available.

sudo systemctl status ssh

If OpenSSH is not installed, install it with:

sudo apt install openssh-server -y

Enable SSH to start automatically after reboots:

sudo systemctl enable ssh
sudo systemctl start ssh

Confirm the service is running:

sudo systemctl status ssh

You should see the service listed as active.

Step 3: Generate an SSH Key Pair

Instead of using passwords, SSH keys provide a much stronger authentication method.

On your local computer, generate an Ed25519 key pair:

ssh-keygen -t ed25519 -C "my-debian-server"

Press Enter to accept the default location.

You will be asked to create a passphrase.

Using a passphrase is recommended because it protects your private key if your computer is compromised.

Once completed, two files will be created:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The private key stays on your computer.

The public key will be copied to the server.

Step 4: Copy the Public Key to the Server

The easiest method is:

ssh-copy-id username@server_ip

Example:

ssh-copy-id [email protected]

Enter your current SSH password when prompted.

If ssh-copy-id is unavailable, manually copy the public key:

cat ~/.ssh/id_ed25519.pub

Copy the output and add it to:

~/.ssh/authorized_keys

on the server.

Step 5: Test Key Authentication

Open a new terminal window.

Do not close your current SSH session.

Connect using:

ssh username@server_ip

If login succeeds without asking for the server password, key authentication is working correctly.

Keep the original SSH session open until all testing is complete.

Many administrators lock themselves out by skipping this step.

Step 6: Disable Root SSH Login

Editing the SSH configuration is the next step.

Open the configuration file:

sudo nano /etc/ssh/sshd_config

Find:

PermitRootLogin yes

Change it to:

PermitRootLogin no

If the line does not exist, add it manually.

This prevents attackers from attempting direct root logins.

Step 7: Disable Password Authentication

While still editing the configuration file, locate:

PasswordAuthentication yes

Change it to:

PasswordAuthentication no

Also verify these settings exist:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

Save the file.

Step 8: Verify the SSH Configuration

Before restarting SSH, validate the configuration syntax.

sudo sshd -t

If no output appears, the configuration is valid.

Any errors should be corrected before continuing.

Step 9: Restart SSH

Apply the changes:

sudo systemctl restart ssh

Check the service status:

sudo systemctl status ssh

Now open another terminal and test SSH access again.

ssh username@server_ip

You should log in successfully using your SSH key.

Password logins should no longer work.

Step 10: Install Fail2ban

Even with key authentication enabled, attackers will continue probing your server.

Fail2ban automatically detects repeated failed login attempts and temporarily blocks the offending IP address.

Install Fail2ban:

sudo apt install fail2ban -y

Enable the service:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Verify it is running:

sudo systemctl status fail2ban

Step 11: Configure Fail2ban for SSH

Create a local configuration file:

sudo nano /etc/fail2ban/jail.local

Add the following:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

What these settings mean:

maxretry = 5 allows five failed login attempts
findtime = 10m counts failures within ten minutes
bantime = 1h blocks the IP address for one hour

Save the file.

Restart Fail2ban:

sudo systemctl restart fail2ban

Step 12: Check Fail2ban Status

View active jails:

sudo fail2ban-client status

Example output:

Status
|- Number of jail: 1
`- Jail list: sshd

View SSH jail details:

sudo fail2ban-client status sshd

This command shows:

Failed login attempts
Banned IP addresses
Current protection status

Step 13: Monitor SSH Login Attempts

To view SSH authentication logs:

sudo journalctl -u ssh -f

To view Fail2ban activity:

sudo journalctl -u fail2ban -f

These logs help identify suspicious login attempts and blocked IPs.

Final Security Checklist

Before considering SSH secure, verify the following:

SSH keys are configured
Root login is disabled
Password authentication is disabled
Fail2ban is active
System packages are updated regularly
SSH configuration passes validation checks
Login testing succeeds from a new terminal session

Conclusion

Securing SSH on Debian 13 does not require expensive security software or complex firewall rules. Switching from passwords to SSH keys removes the most common attack vector, while Fail2ban adds an extra layer of protection against automated login attempts.

For most servers, these two changes alone will eliminate the vast majority of SSH related attacks and significantly improve overall security posture.