Checklist voor SSH-hardening: zo beveilig je een Linux VPS

1. Werk het systeem bij en zet automatische beveiligingsupdates aan

Installeer eerst de openstaande updates: apt update werkt de pakketlijsten bij en apt upgrade installeert de nieuwe versies. [1]

sudo apt update
sudo apt upgrade

Op Ubuntu worden beveiligingsupdates automatisch geïnstalleerd door het pakket unattended-upgrades, dat standaard aanwezig is en één keer per dag draait. Beide waarden in /etc/apt/apt.conf.d/20auto-upgrades moeten “1” zijn, en een proefdraai (dry run) laat zien wat er geïnstalleerd zou worden. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

De server wordt daarbij niet vanzelf herstart, want Unattended-Upgrade::Automatic-Reboot staat standaard op false. Herstart dus zelf als een update dat vereist. [1] Ontbreekt op Debian 12 het pakket of het bestand, installeer dan unattended-upgrades en maak het bestand aan met de twee regels hierboven.

2. Maak een gewone gebruiker met sudo-rechten aan

Werk als een gebruiker met een eigen naam en gebruik sudo voor beheertaken; sudo vraagt om het wachtwoord van die gebruiker zelf, niet om dat van root. Leden van de groep sudo krijgen daarmee volledige root-toegang. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser vraagt om een wachtwoord en een paar optionele gegevens. [2] Kies een lang wachtwoord: SSH gaat straks met sleutels werken, maar sudo blijft om dit wachtwoord vragen. Controleer daarna het account; sudo whoami hoort root te tonen.

su - deploy
sudo whoami

Ontbreekt op Debian 12 het commando sudo, installeer het dan eerst als root met apt install sudo.

3. Genereer op je eigen computer een ed25519-sleutel

Maak het sleutelpaar aan op je eigen computer, niet op de server. Ubuntu raadt het type ed25519 aan, omdat die sleutels korter zijn en minder rekenkracht kosten. ssh-keygen vraagt om een wachtwoordzin die de privésleutel beschermt. [3]

ssh-keygen -t ed25519

Laat de standaardbestandsnaam staan. De privésleutel is ~/.ssh/id_ed25519; de publieke sleutel, die je naar servers kopieert, is ~/.ssh/id_ed25519.pub. [3]

Op Windows voer je hetzelfde commando uit in PowerShell; het sleutelpaar komt dan in de map .ssh van je gebruikersprofiel. Microsoft raadt een lege wachtwoordzin af en waarschuwt dat iedereen die de privésleutel in handen krijgt, onder jouw naam kan inloggen. [4]

ssh-keygen -t ed25519

4. Kopieer de publieke sleutel naar de server

Op Linux en macOS voegt ssh-copy-id je publieke sleutel toe aan ~/.ssh/authorized_keys van de gebruiker op de server. [3]

ssh-copy-id deploy@203.0.113.10

Microsoft gebruikt in zijn handleiding in plaats daarvan PowerShell of scp om sleutels te kopiëren. [4] Voor een Linux-server voegt dit commando je sleutel toe en geeft het alleen jou schrijfrechten op de map en het bestand:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Voordat sshd een login accepteert, controleert de daemon deze rechten via de optie StrictModes, die standaard aan staat. [5] Voer daarna in een nieuwe terminal ssh deploy@203.0.113.10 uit: je moet nu kunnen inloggen zonder het wachtwoord van het account. Lukt dat niet, volg dan het SSH-log van de server terwijl je het opnieuw probeert: [3]

sudo journalctl -fu ssh.service

5. Zet je instellingen in een drop-in-bestand

Op Ubuntu begint /etc/ssh/sshd_config met Include /etc/ssh/sshd_config.d/*.conf, en OpenSSH houdt voor de meeste instellingen de eerste waarde aan die het leest. Bestanden in die map hebben dus voorrang op het hoofdbestand. [3] Bestanden die via Include worden ingelezen, komen in lexicografische volgorde aan de beurt, en per optie geldt de eerste waarde die sshd tegenkomt, [5] dus noem je eigen bestand 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Volgens de manpage van sshd_config:

• PermitRootLogin no voorkomt dat root via SSH inlogt. De standaardwaarde, prohibit-password, weigert wachtwoorden voor root, maar accepteert nog wel sleutels. [5]
• PasswordAuthentication no schakelt inloggen met een wachtwoord uit; dat is standaard toegestaan. [5]
• KbdInteractiveAuthentication no schakelt keyboard-interactive-authenticatie uit, een aparte methode die ook standaard aan staat; de oude naam van deze optie is ChallengeResponseAuthentication. [5]
• AllowUsers deploy (optioneel) laat alleen de genoemde gebruikers inloggen. Anders dan bij de meeste opties vult elke AllowUsers-regel de lijst aan. [5] Let op de exacte spelling van de naam, anders komt niemand meer binnen.

Behandel het sudo-account vanaf nu als root: volgens de toelichting bij het openssh-pakket van Ubuntu is elk account van waaruit je root kunt worden, voor aanvallers van buitenaf gelijkwaardig aan root. [6] Controleer op Debian 12 eerst met grep -n Include /etc/ssh/sshd_config of de Include-regel er staat.

6. Zoek bestanden die wachtwoorden weer aanzetten

Omdat de eerste waarde wint, heeft elk bestand dat in de sortering vóór het jouwe staat, voorrang. Doorzoek de map:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Op cloudimages schrijft cloud-init de SSH-instellingen die het beheert naar /etc/ssh/sshd_config.d/50-cloud-init.conf, als sshd_config die map inleest. [7] Staat in dat bestand PasswordAuthentication yes, dan wint het van alle bestanden die later in de sortering staan; daarom begint de naam van jouw bestand met 00. Zet de optie daar ook op no, zodat de bestanden met elkaar overeenkomen.

7. Test de configuratie en herstart SSH

Test de bestanden voordat je herstart: een foute instelling kan ervoor zorgen dat sshd niet start, en SSH is misschien je enige toegang tot de server. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Los eerst alles op wat sshd -t meldt. Houd na de herstart je sessie open en test vanuit een tweede terminal:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

De eerste login moet lukken en de tweede moet worden geweigerd. Mislukt je login, draai de wijziging dan terug in de sessie die nog open is en bekijk het SSH-log uit stap 4. [3]

8. Wijzig de poort op Ubuntu 24.04 (optioneel)

Op Ubuntu 24.04 luistert ssh.socket via socketactivering van systemd op poort 22. Een generator zet de Port-regels in sshd_config en de bijbehorende drop-in-bestanden om in socketinstellingen. Na een poortwijziging laad je systemd daarom opnieuw en herstart je ssh.socket. [6]

sshd accepteert meer dan één Port-regel, [5] dus laat 22 staan terwijl je de nieuwe poort test:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Test de nieuwe poort vanuit een tweede terminal. Verwijder daarna Port 22, voer de drie commando’s opnieuw uit en gebruik in stap 9 en 10 poort 2222.

ssh -p 2222 deploy@203.0.113.10

Controleer op Debian 12 eerst of de socket in gebruik is. Is die niet actief, dan is een herstart van de dienst genoeg om de wijziging toe te passen.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Sta SSH toe in UFW en schakel UFW daarna in

UFW staat na de installatie uit en weigert, eenmaal ingeschakeld, standaard binnenkomend verkeer. De manpage waarschuwt dat ufw enable SSH-verbindingen kan verbreken, dus voeg eerst de SSH-regel toe. [8]

Gebruik voor SSH limit in plaats van allow. Een limit-regel laat verbindingen nog steeds toe, maar weigert een adres dat binnen 30 seconden 6 of meer verbindingen probeert te openen. Voeg niet beide regels toe, want UFW past de eerste regel toe die overeenkomt. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Als je UFW via SSH inschakelt, vraagt UFW om een bevestiging. [8] Heb je SSH naar een andere poort verplaatst, pas limit dan toe op 2222/tcp. Ontbreekt op Debian 12 het commando, installeer UFW dan eerst. Wil je SSH helemaal van het openbare internet halen, maak het dan alleen bereikbaar via een privénetwerk met WireGuard. Voor bescherming die al vóór je server begint, lees je onze checklist voor DDoS-bescherming van een VPS.

10. Voeg Fail2ban toe met de sshd-jail

Op Ubuntu 24.04 levert het pakket /etc/fail2ban/jail.d/defaults-debian.conf mee. Dat bestand schakelt de sshd-jail in, stelt backend = systemd in en laat blokkades via nftables lopen. [9] De systemd-backend leest het systemd-journal, dus de jail heeft geen apart logbestand nodig. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Volgens de eigen jail.conf van Fail2ban wordt een adres 10 minuten geblokkeerd zodra vanaf dat adres binnen 10 minuten 5 inlogpogingen mislukken. In datzelfde bestand staat dat je het niet moet bewerken: zet je wijzigingen in jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Vervang 198.51.100.7 door je eigen vaste adres, of haal het weg. De standaard-jail gebruikt port = ssh; heb je SSH verplaatst, voeg dan port = 2222 toe. [10] Laat op Debian 12 backend = systemd hier staan en installeer python3-systemd, de Python-bibliotheek voor systemd die deze backend gebruikt. [10] Herstart daarna Fail2ban en controleer of het draait:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Controleer wat er verder nog luistert

Elke open poort is een extra weg naar binnen. UFW kan een overzicht van luisterende poorten tonen: elke luisterende TCP-poort en open UDP-poort, met het adres (* betekent alle interfaces), het programma erachter en de regels die van toepassing zijn. [8]

sudo ufw show listening

Een dienst die aan 127.0.0.1 gebonden is, is alleen vanaf de server zelf bereikbaar. Openbaar bereikbare diensten die je niet nodig hebt, schakel je uit met systemctl disable --now, zoals de toelichting bij het openssh-pakket van Ubuntu dat voor ssh.socket doet. [6]

sudo systemctl disable --now SERVICE_NAME