SSH beveiligen op een VPS: stappenplan

Waarom SSH als eerste moet worden beveiligd

SSH is de methode waarmee u uw server beheert, wat het tot het slot maakt dat elke aanvaller als eerste probeert te forceren. Zodra een VPS online is, beginnen scanners binnen enkele minuten met het raden van gebruikersnamen en wachtwoorden op poort 22. U kunt dit proces in uw logs zien gebeuren. Het beveiligen van SSH draait om het wegnemen van de gegevens die aanvallers kunnen raden: schakel wachtwoordauthenticatie volledig uit, sta geen root-login toe en accepteer uitsluitend cryptografische sleutels. Zodra u dit heeft gedaan, kan het constant raden niet langer slagen, omdat er geen wachtwoord is om te achterhalen.

Dit gaat ervan uit dat SSH al correct functioneert. Als u kunt inloggen, kunt u de beveiliging aanscherpen. Voer de stappen in de juiste volgorde uit en houd uw huidige sessie open totdat een nieuwe sessie succesvol is getest; zo voorkomt u dat u zichzelf buitensluit door een fout.

Stap 1: Controleer eerst of authenticatie met sleutels werkt

Authenticatie met sleutels vervangt een wachtwoord door een sleutelpaar: een privésleutel die op uw computer blijft en een publieke sleutel die u op de server plaatst. De server verifieert of u in het bezit bent van de privésleutel zonder dat deze ooit uw machine verlaat. Voordat u wachtwoorden uitschakelt, moet u bevestigen dat sleutels werken; anders sluit u uzelf buiten.

Maak op uw eigen computer een sleutel aan als u er nog geen heeft:

ssh-keygen -t ed25519

Kopieer het publieke deel naar de server:

ssh-copy-id user@your-server

Open vervolgens een nieuwe SSH-sessie. Als u toegang krijgt zonder om een wachtwoord te worden gevraagd, werkt uw sleutel en kunt u veilig wachtwoorden uitschakelen. Als u wordt tegengehouden met Permission denied (publickey), verbergt die specifieke fout vijf verschillende problemen, en de ssh -v-uitvoer vertelt u welke van toepassing is voordat u andere wijzigingen aanbrengt. Als sleutels nieuw voor u zijn, of als u meer dan één computer gebruikt, legt de basis van SSH-sleutelbeheer het volledige model uit: één sleutel per apparaat, de rechten die sshd vereist en hoe u een sleutel intrekt wanneer een laptop vermist raakt.

Stap 2: sshd beveiligen met een drop-in bestand

Bewerk /etc/ssh/sshd_config niet rechtstreeks. Ubuntu 24.04 leest drop-in bestanden vanuit /etc/ssh/sshd_config.d/. Een klein bestand op die locatie is overzichtelijker, blijft behouden bij pakket-upgrades en is eenvoudig te verwijderen als er iets misgaat. De naam is van belang: sshd hanteert de eerste waarde die het leest voor elke instelling. Ubuntu cloud-images bevatten 50-cloud-init.conf met PasswordAuthentication yes in deze map. Noem uw bestand 00- zodat het alfabetisch vóór dat bestand komt en voorrang krijgt; een 99- bestand wordt stilzwijgend genegeerd. Maak het bestand aan:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Voeg de volgende inhoud toe:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Elke regel sluit een toegangspoort. PasswordAuthentication no is de belangrijkste: wanneer wachtwoorden zijn uitgeschakeld, heeft een brute-force aanval geen doelwit meer. KbdInteractiveAuthentication no sluit een tweede methode die op wachtwoordauthenticatie lijkt. PermitRootLogin no betekent dat een aanvaller zowel uw gebruikersnaam moet kennen als in het bezit moet zijn van uw sleutel, in plaats van alleen het root-account aan te vallen dat op elke server aanwezig is.

Stap 3: Test de configuratie en herlaad

Controleer de configuratie op fouten voordat u deze toepast, zodat een typefout de service niet verstoort:

sudo sshd -t

Als er geen uitvoer verschijnt, is de configuratie geldig. Herlaad SSH:

sudo systemctl reload ssh

Controleer vervolgens welke instellingen sshd daadwerkelijk gebruikt, zodat u ziet of een drop-in bestand is overschreven door een ander bestand:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Beide zouden no moeten aangeven. Open nu, zonder uw huidige sessie te sluiten, een nieuwe sessie vanuit een andere terminal. Als u kunt inloggen met uw sleutel, bent u klaar. Mocht er iets mis zijn, dan is uw eerste sessie nog open om het te herstellen. Deze overlap dient als vangnet; sla deze stap daarom nooit over.

Stap 4: De optionele niet-standaard poort

Het verplaatsen van SSH van poort 22 naar bijvoorbeeld 2222 verhoogt de veiligheid niet in de praktijk, omdat een vastberaden aanvaller alle poorten scant. Het vermindert wel de ruis in de logs, aangezien de meeste geautomatiseerde scanners alleen poort 22 proberen. Als u dit wilt, voeg dan Port 2222 toe aan uw drop-in bestand, sta de nieuwe poort eerst toe in de firewall, voer daarna sudo systemctl daemon-reload && sudo systemctl restart ssh.socket uit en maak verbinding met ssh -p 2222. Op Ubuntu 24.04 beheert ssh.socket de luisterende poort, waardoor een standaard reload ssh sshd op poort 22 laat staan; het herstarten van de socket is nodig om de nieuwe poort te activeren. Beschouw dit als netheid, niet als beveiliging.

Stap 5: Voeg aanvullende verdedigingslagen toe

Beveiligde SSH-keys vormen de basis, met daarbovenop nog twee extra lagen.

Fail2ban monitort uw logs en blokkeert IP-adressen die herhaaldelijk inlogpogingen laten mislukken. Dit vermindert ruis van scanners en verwijdert deze vroegtijdig. Het is een natuurlijke aanvulling op authenticatie uitsluitend via keys: zie Fail2ban op Ubuntu om SSH-aanvallen te stoppen.

Nog effectiever is het om SSH volledig af te schermen van het publieke internet. Als u SSH achter een WireGuard VPN plaatst en poort 22 in de firewall beperkt tot de tunnel, kan niemand buiten het VPN de service bereiken. Brute-force aanvallen worden hiermee onmogelijk in plaats van enkel bemoeilijkt. Dit alles gaat uit van een firewall met een default-deny beleid, zoals UFW geconfigureerd op de VPS.

SSH is slechts één onderdeel van een uitgebreidere checklist: de eerste 10 minuten op een nieuwe VPS zet de stappen in de juiste volgorde, en automatische beveiligingsupdates op Ubuntu houden het systeem daarna up-to-date. Het op slot doen van de deur biedt echter geen bescherming voor de services die erachter draaien. Als op dezelfde VPS een wachtwoordkluis draait, behandelt een hardening-ronde voor Vaultwarden de twee zaken waar key-authenticatie geen invloed op heeft: het admin-token en het back-upbestand.

FAQ

Hoe schakel ik wachtwoordauthenticatie voor SSH uit op Ubuntu 24.04?

Maak een drop-in bestand aan op /etc/ssh/sshd_config.d/00-hardening.conf (het 00 voorvoegsel zorgt ervoor dat dit bestand vóór 50-cloud-init.conf wordt ingelezen, omdat PasswordAuthentication yes anders voorrang krijgt; sshd hanteert de eerste waarde die het leest). Voeg hierin PasswordAuthentication no en KbdInteractiveAuthentication no toe, voer sudo sshd -t uit om de configuratie te controleren en voer daarna sudo systemctl reload ssh uit. Controleer of inloggen met een sleutel werkt in een nieuwe sessie voordat u de wijziging definitief maakt. Het bewerken van een drop-in in plaats van sshd_config zorgt ervoor dat uw wijzigingen behouden blijven bij pakketupdates en is eenvoudig ongedaan te maken.

Moet ik root-login via SSH uitschakelen?

Ja. Stel PermitRootLogin no in zodat niemand direct als root kan inloggen. Log in als uw normale gebruiker en gebruik sudo voor beheertaken. Het root-account bestaat op elk Linux-systeem; als dit bereikbaar blijft, geeft u een aanvaller een bekende gebruikersnaam om op te richten. Door dit uit te schakelen, moet een aanvaller zowel uw accountnaam kennen als over uw sleutel beschikken.

Maakt het wijzigen van de SSH-poort mijn server veiliger?

Niet noemenswaardig. Door de poort te verplaatsen van 22, bent u onzichtbaar voor eenvoudige scanners die alleen op poort 22 zoeken, wat de ruis in uw logs vermindert. Een serieuze aanvaller scant echter alle poorten en vindt de service alsnog. Authenticatie uitsluitend via sleutels is wat inbraken daadwerkelijk voorkomt. Als u de poort wijzigt, open de nieuwe poort dan eerst in de firewall en voer daarna sudo systemctl daemon-reload && sudo systemctl restart ssh.socket uit; op Ubuntu 24.04 beheert de socket de listener en een standaard reload laat sshd op poort 22 actief.

Heb ik Fail2ban nodig als ik SSH-sleutels gebruik?

Het is optioneel, maar nog steeds nuttig. Bij authenticatie uitsluitend via sleutels kan het raden van wachtwoorden niet slagen, dus Fail2ban is niet de factor die aanvallers buitenhoudt. Het beperkt wel het aantal mislukte inlogpogingen vanaf één adres, wat de logbestanden opschoont van scanner-ruis en herhaaldelijke aanvallers vroegtijdig blokkeert. Een trage, gedistribueerde aanval blijft echter vaak onder de drempelwaarde voor een ban. Gebruik het als extra laag bovenop sleutelauthenticatie en houd SSH bij voorkeur achter een VPN.

Hoe herstel ik de toegang als ik mezelf buitensluit van SSH?

Gebruik de webconsole van uw provider; deze maakt verbinding met de server via een seriële of VNC-verbinding die niet via SSH verloopt. Vanaf daar kunt u inloggen, het sshd drop-in bestand corrigeren en de service herladen. Dit is precies de reden waarom u een nieuwe SSH-configuratie altijd test in een tweede terminal voordat u de eerste sessie sluit, en waarom sleutelauthenticatie al moet werken voordat u wachtwoorden uitschakelt.