SSH Security: Key-Based Login and fail2ban Guide

The moment a game server, VPS or any Linux machine goes online, SSH security becomes your most critical line of defense. That is because the first thing attackers try is to fire hundreds of username–password combinations at the open port 22 using automated tools. In this guide I walk through setting up key-based login, fully disabling password authentication, changing the port, and automatically blocking brute-force attacks with fail2ban — step by step, with real, working commands.

Why a password alone is not enough

Passwords can be guessed, leaked and are vulnerable to dictionary attacks. If you check your server logs (sudo journalctl -u ssh or /var/log/auth.log), you will see hundreds of failed login attempts from IPs you have never heard of. An SSH key, on the other hand, is a practically unguessable asymmetric cryptographic pair: the private key stays with you, while the public key is copied to the server. The server only lets in whoever holds the matching private key. Set up correctly, the password brute-force threat disappears entirely.

1. Generating an SSH key pair

On your own computer (not the server), create a modern, secure ed25519 key:

ssh-keygen -t ed25519 -C "aslain@laptop"

The command asks for a file path and an optional passphrase. The passphrase encrypts your private key on disk with an extra password; it provides a second barrier if your laptop is stolen — don't skip it. You end up with two files: the private key ~/.ssh/id_ed25519 and the public key ~/.ssh/id_ed25519.pub. The one with the .pub extension is shareable; never share the one without an extension.

2. Copying the public key to the server

The easiest method is ssh-copy-id. It adds your public key to the server's ~/.ssh/authorized_keys file with the correct permissions:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip

If ssh-copy-id isn't available, you can add the key manually. Permissions must be correct, otherwise SSH ignores the key:

ssh user@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" < ~/.ssh/id_ed25519.pub

Now, in a new terminal, test whether you can log in without a password (using only the passphrase):

ssh user@server_ip

Verify this without closing your current session; if the key doesn't work, you can still fix the error while password login is active.

3. Disabling password and root login

Once you have confirmed that key login works, disable password authentication. The configuration lives in /etc/ssh/sshd_config. Back it up before editing:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Find these lines (add them if missing) and set their values:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no

PermitRootLogin prohibit-password lets root in only with a key; for stronger security set it to no and work with a normal user plus sudo. On some systems these settings can be overridden by files under /etc/ssh/sshd_config.d/; check there too. Test the syntax before applying, then restart the service:

sudo sshd -t
sudo systemctl restart ssh

On some distributions the service is named sshd (systemctl restart sshd). After restarting, open a new connection without closing the current session and confirm key login again.

4. Changing the port: less noise, not a fix

Moving SSH off the standard port 22 to something else (e.g. 2222 or 49222) keeps most automated scanning bots out of your logs. This is a noise-reduction measure, not a security measure — the real protection is keys and fail2ban. Still, keeping logs clean is valuable:

Port 49222

If a firewall (such as UFW) is running on the server, open the new port before restarting the service, otherwise you'll lock yourself out:

sudo ufw allow 49222/tcp
sudo systemctl restart ssh

You now have to specify the port when connecting: ssh -p 49222 user@server_ip. To avoid typing it repeatedly, add a shortcut to your local ~/.ssh/config file:

Host myserver
    HostName server_ip
    User user
    Port 49222
    IdentityFile ~/.ssh/id_ed25519

From then on, just ssh myserver is enough.

5. Automate brute-force protection with fail2ban

Even with passwords disabled, bots keep trying to connect. fail2ban watches the logs and temporarily bans, via the firewall, any IP that makes too many failed attempts within a set window. Installation on Debian/Ubuntu:

sudo apt update && sudo apt install fail2ban -y

Don't configure directly in jail.conf; use a jail.local override file so package updates don't overwrite your settings:

sudo nano /etc/fail2ban/jail.local

Define a jail for SSH inside it. If you changed the port, put it on the port line:

[sshd]
enabled = true
port = 49222
maxretry = 4
findtime = 10m
bantime = 1h

This setting bans an IP for 1 hour after 4 failed attempts within 10 minutes. To punish repeat offenders for longer, you can also add bantime.increment = true. Start the service and check its status:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

The output shows the number and list of banned IPs. If you accidentally ban an IP (for example, yourself), you can release it manually:

sudo fail2ban-client set sshd unbanip 203.0.113.10

6. A few extra hardening steps

• Against locking yourself out: after any critical change, always keep a second session open and test the new connection.
• Firewall: with UFW, open only the necessary ports (sudo ufw default deny incoming) and close everything except your game server ports.
• Stay updated: run sudo apt update && sudo apt upgrade regularly; SSH vulnerabilities are mostly exploited on out-of-date systems.
• Idle timeout: close idle sessions with ClientAliveInterval 300.

Frequently Asked Questions

How do I get in if I lose my private key?

If you disabled password login and lost your only key, you can't get in via SSH. So either add multiple keys to authorized_keys, or keep your provider's console/recovery access (the web console in your VPS panel) ready. You can generate a new key and add it from there.

Is changing the port enough security on its own?

No. Changing the port only reduces automated scanning noise; a targeted attacker will scan your port easily. Real security comes from disabling passwords and using keys, plus adding a layered defense like fail2ban.

Why does fail2ban ban me occasionally?

It usually happens because of repeated attempts with a wrong passphrase, wrong username, or an old key. Check with fail2ban-client status sshd and release yourself with unbanip; you can also add your own static IP to the ignoreip line.

Want to make your server bulletproof? Let's harden the SSH and firewall of your game server, VPS or web hosting setup together. Get in touch and let's secure your infrastructure from end to end.