SSH-beveiliging: sleutel-login en fail2ban-gids

Zodra een gameserver, VPS of welke Linux-machine dan ook online gaat, wordt SSH-beveiliging je meest kritieke verdedigingslinie. Het eerste wat aanvallers namelijk proberen, is honderden gebruikersnaam–wachtwoordcombinaties naar de open poort 22 te sturen met geautomatiseerde tools. In deze gids laat ik stap voor stap zien hoe je sleutel-login instelt, wachtwoordauthenticatie volledig uitschakelt, de poort wijzigt en brute-force-aanvallen automatisch blokkeert met fail2ban — met echte, werkende commando's.

Waarom een wachtwoord alleen niet genoeg is

Wachtwoorden kunnen worden geraden, gelekt en zijn kwetsbaar voor woordenboekaanvallen. Als je de serverlogs bekijkt (sudo journalctl -u ssh of /var/log/auth.log), zie je honderden mislukte inlogpogingen vanaf IP's die je niet kent. Een SSH-sleutel daarentegen is een praktisch onraadbaar asymmetrisch cryptografisch paar: de privésleutel blijft bij jou, terwijl de publieke sleutel naar de server wordt gekopieerd. De server laat alleen degene binnen die de bijbehorende privésleutel heeft. Correct ingesteld verdwijnt de dreiging van wachtwoord-brute-force volledig.

1. Een SSH-sleutelpaar genereren

Maak op je eigen computer (niet op de server) een moderne, veilige ed25519-sleutel:

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

Het commando vraagt om een bestandspad en een optionele passphrase. De passphrase versleutelt je privésleutel op schijf met een extra wachtwoord; het vormt een tweede barrière als je laptop wordt gestolen — sla het niet over. Je krijgt twee bestanden: de privésleutel ~/.ssh/id_ed25519 en de publieke sleutel ~/.ssh/id_ed25519.pub. Die met de extensie .pub mag je delen; deel die zonder extensie nooit.

2. De publieke sleutel naar de server kopiëren

De eenvoudigste methode is ssh-copy-id. Die voegt je publieke sleutel met de juiste permissies toe aan het bestand ~/.ssh/authorized_keys op de server:

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

Als ssh-copy-id niet beschikbaar is, kun je de sleutel handmatig toevoegen. De permissies moeten kloppen, anders negeert SSH de sleutel:

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

Test nu in een nieuw terminalvenster of je zonder wachtwoord (alleen met de passphrase) kunt inloggen:

ssh gebruiker@server_ip

Controleer dit zonder je huidige sessie te sluiten; als de sleutel niet werkt, kun je de fout nog herstellen zolang wachtwoordlogin actief is.

3. Wachtwoord- en root-login uitschakelen

Zodra je hebt bevestigd dat sleutel-login werkt, schakel je wachtwoordauthenticatie uit. De configuratie staat in /etc/ssh/sshd_config. Maak een back-up voordat je bewerkt:

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

Zoek deze regels (voeg ze toe als ze ontbreken) en stel hun waarden in:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no

PermitRootLogin prohibit-password laat root alleen met een sleutel binnen; voor sterkere beveiliging zet je het op no en werk je met een gewone gebruiker plus sudo. Op sommige systemen kunnen deze instellingen worden overschreven door bestanden onder /etc/ssh/sshd_config.d/; kijk daar ook. Test de syntaxis voordat je toepast en herstart daarna de service:

sudo sshd -t
sudo systemctl restart ssh

Op sommige distributies heet de service sshd (systemctl restart sshd). Open na het herstarten een nieuwe verbinding zonder de huidige sessie te sluiten en bevestig de sleutel-login opnieuw.

4. De poort wijzigen: minder ruis, geen oplossing

SSH van de standaardpoort 22 naar iets anders verplaatsen (bijv. 2222 of 49222) houdt de meeste geautomatiseerde scanbots uit je logs. Dit is een maatregel om ruis te verminderen, geen beveiligingsmaatregel — de echte bescherming zijn sleutels en fail2ban. Toch is schone logs houden waardevol:

Port 49222

Als er een firewall (zoals UFW) op de server draait, open dan de nieuwe poort voordat je de service herstart, anders sluit je jezelf buiten:

sudo ufw allow 49222/tcp
sudo systemctl restart ssh

Je moet nu de poort opgeven bij het verbinden: ssh -p 49222 gebruiker@server_ip. Om het niet steeds te hoeven typen, voeg je een snelkoppeling toe aan je lokale ~/.ssh/config-bestand:

Host mijnserver
    HostName server_ip
    User gebruiker
    Port 49222
    IdentityFile ~/.ssh/id_ed25519

Daarna is alleen ssh mijnserver genoeg.

5. Brute-force-bescherming automatiseren met fail2ban

Zelfs met wachtwoorden uitgeschakeld blijven bots proberen verbinding te maken. fail2ban bewaakt de logs en blokkeert via de firewall tijdelijk elk IP dat binnen een ingesteld venster te veel mislukte pogingen doet. Installatie op Debian/Ubuntu:

sudo apt update && sudo apt install fail2ban -y

Configureer niet rechtstreeks in jail.conf; gebruik een jail.local-overschrijfbestand zodat pakketupdates je instellingen niet overschrijven:

sudo nano /etc/fail2ban/jail.local

Definieer daarin een jail voor SSH. Als je de poort hebt gewijzigd, zet die op de port-regel:

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

Deze instelling blokkeert een IP gedurende 1 uur na 4 mislukte pogingen binnen 10 minuten. Om herhaalde overtreders langer te straffen, kun je ook bantime.increment = true toevoegen. Start de service en controleer de status:

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

De uitvoer toont het aantal en de lijst van geblokkeerde IP's. Als je per ongeluk een IP blokkeert (bijvoorbeeld jezelf), kun je het handmatig vrijgeven:

sudo fail2ban-client set sshd unbanip 203.0.113.10

6. Een paar extra hardening-stappen

• Tegen jezelf buitensluiten: houd na elke kritieke wijziging altijd een tweede sessie open en test de nieuwe verbinding.
• Firewall: open met UFW alleen de noodzakelijke poorten (sudo ufw default deny incoming) en sluit alles behalve je gameserver-poorten.
• Blijf up-to-date: voer regelmatig sudo apt update && sudo apt upgrade uit; SSH-kwetsbaarheden worden vooral op verouderde systemen misbruikt.
• Inactiviteitstime-out: sluit inactieve sessies met ClientAliveInterval 300.

Veelgestelde vragen

Hoe kom ik binnen als ik mijn privésleutel verlies?

Als je wachtwoordlogin hebt uitgeschakeld en je enige sleutel kwijt bent, kun je niet meer via SSH binnenkomen. Voeg dus meerdere sleutels toe aan authorized_keys, of houd de console-/hersteltoegang van je provider (de webconsole in je VPS-paneel) gereed. Daar kun je een nieuwe sleutel genereren en toevoegen.

Is de poort wijzigen op zichzelf genoeg beveiliging?

Nee. De poort wijzigen vermindert alleen de ruis van geautomatiseerd scannen; een gerichte aanvaller scant je poort moeiteloos. Echte beveiliging komt van wachtwoorden uitschakelen en sleutels gebruiken, plus een gelaagde verdediging zoals fail2ban.

Waarom blokkeert fail2ban mij af en toe?

Dat gebeurt meestal door herhaalde pogingen met een verkeerde passphrase, verkeerde gebruikersnaam of een oude sleutel. Controleer met fail2ban-client status sshd en geef jezelf vrij met unbanip; je kunt ook je eigen statische IP toevoegen aan de ignoreip-regel.

Wil je je server kogelvrij maken? Laten we samen de SSH en firewall van je gameserver, VPS of webhosting verstevigen. Neem contact op en we beveiligen je infrastructuur van begin tot eind.