What are we building?

By the end, Fail2ban 1.1 on your Debian 13 monitors the SSH logins and, after too many failed attempts, bans the attacking IP for a defined time – via a firewall rule. Your own IP is on a whitelist so this never hits you. You can view bans, set them manually and lift them again.

Prerequisites

• A hardened server (key login) with an active firewall
• Your own public IP – find it e.g. via wieistmeineip.de or curl -s ifconfig.me from your local machine

Step by step

Before we configure, three terms that explain the whole tool:

• Filter – a pattern that detects a “failed login” in the log (for SSH, Fail2ban brings this ready-made).
• Jail – connects a filter with a log source and the rules “how often in what time frame”. The sshd jail monitors the SSH logins.
• Action – what happens when it’s exceeded: by default a firewall rule that blocks the IP for bantime.

In short: filter detects failed attempts → jail counts them → action bans. Everything you configure below is one of these three knobs.

Step 1: Install Fail2ban

sudo apt update
sudo apt install -y fail2ban

Check the version:

fail2ban-client --version

Fail2Ban v1.1.0

Step 2: Your own configuration in jail.local

Create the file:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# How long the ban lasts
bantime = 1h
# Time window in which the failed attempts count
findtime = 10m
# This many failed attempts are allowed, then a ban
maxretry = 5
# Your own IP(s) – will NEVER be banned
ignoreip = 127.0.0.1/8 ::1 YOUR_OWN_IP

[sshd]
enabled = true

Line by line:

• bantime = 1h – ban duration. For stubborn cases, see the escalation in step 5.
• findtime + maxretry – “5 failed attempts within 10 minutes → ban”.
• ignoreip – the most important line: enter your own IP here so you don’t lock yourself out. If you have a changing IP at home, better use access via a fixed point (a VPN later) instead of a broad allowance.
• [sshd] enabled = true – activates the SSH jail.

Step 3: Start and enable the service

sudo systemctl enable --now fail2ban

enable --now starts the service immediately and ensures it runs again automatically after a reboot. Check that it runs cleanly:

sudo systemctl status fail2ban

You should see active (running). After every change to jail.local, reload the configuration with sudo systemctl reload fail2ban.

Step 4: Check the status

This is how you see which jails are active:

sudo fail2ban-client status

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

And the details of the SSH jail:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

The Journal matches line confirms that Fail2ban reads the systemd journal. Currently banned rises as soon as someone gets it wrong too often.

Step 5: Manage bans – and escalate them

Manually unban an IP (e.g. when a colleague mistyped):

sudo fail2ban-client set sshd unbanip 203.0.113.45

Ban an IP immediately:

sudo fail2ban-client set sshd banip 203.0.113.45

Against especially stubborn attackers, an escalating ban time pays off: whoever comes back is banned for longer. Add to the [DEFAULT] block:

bantime.increment = true
bantime.maxtime = 1w

With that, Fail2ban doubles the ban time each time the same IP reoffends – up to a maximum of one week. After the change, sudo systemctl reload fail2ban.

When things go wrong

Maintenance & backups

• Keep an eye on bans: sudo fail2ban-client status sshd shows at any time how many IPs are currently banned. A look at the journal (journalctl -u fail2ban) shows the history.
• More jails: as soon as services with their own login are added (e.g. a web app), you can activate matching jails – following the same pattern as [sshd].
• Back up jail.local: your configuration is quickly restored but belongs in the backup of your server configuration.
• Outlook CrowdSec: Fail2ban protects your host based on your logs. The modern successor CrowdSec later adds collaborative intrusion prevention (shared block lists) to this – we build it in a dedicated recipe once the reverse proxy is up. To get started, Fail2ban is exactly right.

With that, the security foundation is complete: key login, two firewall layers (UFW + netcup firewall), automatic updates and active brute-force protection. Your server is now not just set up, but solidly secured.

What are we building?

By the end you log in with an SSH key instead of a password, and neither root login nor password login is possible from outside. This makes the automated password-guessing attacks that hit every publicly reachable server around the clock run completely into the void. Tested with OpenSSH on Debian 13.

Prerequisites

• A set-up server with a sudo user
• Access to the VNC console in the netcup SCP as a safety line in case you lock yourself out

Step by step

Step 1: Generate an SSH key pair

If you don’t have a key yet, generate an Ed25519 key pair on your own machine (not on the server!):

ssh-keygen -t ed25519

You can accept the suggested storage location with Enter. Set a passphrase – it protects the key if your machine falls into the wrong hands. Two files are created: ~/.ssh/id_ed25519 (private, stays with you) and ~/.ssh/id_ed25519.pub (public, goes on the server).

Step 2: Transfer the public key

ssh-copy-id appends your public key to the ~/.ssh/authorized_keys file of your server user – with the correct file permissions:

ssh-copy-id koch@YOUR_SERVER_IP

Test right afterwards that key login works:

ssh koch@YOUR_SERVER_IP

You should now be logged in without a server password (only the passphrase of your key may be requested). Only once that works do we continue – in the next step we disable password login.

Step 3: Disable password login and root login

Open the SSH server configuration:

sudo nano /etc/ssh/sshd_config

Set (or uncomment) these two lines:

PermitRootLogin no
PasswordAuthentication no

PermitRootLogin no blocks direct root login completely, PasswordAuthentication no allows only key logins.

Step 4: Test the configuration and restart SSH

Check the configuration for syntax errors before you restart – a typo would otherwise take the SSH service down:

sudo sshd -t

No output means: all good. Then apply it:

sudo systemctl restart ssh

To verify: sudo systemctl status ssh should show active (running), and a login attempt as root must now be rejected with Permission denied (publickey).

When things go wrong

Maintenance & backups

• Back up the private key: Without ~/.ssh/id_ed25519 you can only reach the server via the VNC console. Back up the key encrypted (e.g. in a password manager) or add a second key from another device to authorized_keys.
• Keep an eye on logins: sudo journalctl -u ssh --since today shows you all login attempts. Failed attempts on port 22 are normal and, thanks to the key requirement, harmless – you can automatically ban such bots later with Fail2ban.
• Updates: OpenSSH gets its security updates through the normal apt upgrade – so keep the server up to date, ideally automated.

What are we building?

By the end of this tutorial, your VPS runs a current Debian 13 with all security updates, and you work with your own user with sudo rights instead of permanently as root. That’s the foundation for all the other recipes in the Serverküche – from hardening SSH to your first application.

Prerequisites

• An ordered netcup server with the credentials from your customer account
• A terminal on your machine (Linux/macOS) or an SSH client like PuTTY (Windows)

Not sure which server size you even need? The server calculator estimates the RAM and CPU you’ll need for your planned services and suggests a matching netcup plan.

Step by step

Step 1: Log in via SSH

Log in with your server’s IP address as root. You’ll find the IP and the password in the credentials from your customer account:

ssh root@YOUR_SERVER_IP

On the very first login, SSH asks whether you want to trust the server:

The authenticity of host 'YOUR_SERVER_IP' can't be established.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Answer yes – your machine remembers the server from now on. After that you land on a prompt like root@v12345:~#.

Step 2: Update the system

Freshly delivered images are rarely up to date. So the first thing to do is fetch all updates – security updates in particular should never wait:

apt update && apt upgrade -y

apt update fetches the current package lists, apt upgrade -y installs all available updates without prompting.

Step 3: Create a sudo user

Don’t work as root permanently: a typo with full rights can wreck the entire system, and having your own user is the prerequisite for disabling root login completely later. Create a user – we’ll call it koch (“cook”) here, but you can pick any name:

adduser koch

You’ll be asked for a password and a few optional details (you can skip the details with Enter). After that, give the user sudo rights:

usermod -aG sudo koch

Step 4: Test the new user

Check in a new terminal session (keep the root session open!) that login and sudo work:

ssh koch@YOUR_SERVER_IP
sudo whoami

After entering your password, sudo whoami should return root. From now on you continue working with this user.

When things go wrong

Maintenance & backups

• Updates: You should schedule sudo apt update && sudo apt upgrade at least weekly – or automate security updates with unattended-upgrades.
• Snapshots: Create a snapshot in the netcup Server Control Panel (SCP) before bigger changes. It’s your safety line while you don’t have a proper backup strategy yet – but a snapshot does not replace a backup outside the server.
• Credentials: Keep the root password safe (password manager). Via the VNC console in the SCP you can still reach the server even when SSH is stuck.

You’ll find both in the server overview of the SCP: the VNC console is under the “Bildschirm” (Display) tab, and the remaining snapshot quota is shown in the status block.