SSH beveiligen op een VPS

Waarom SSH de eerste prioriteit is voor hardening

SSH is de methode waarmee u uw server beheert. Dit maakt het het primaire doelwit voor aanvallers. Zodra een VPS online is, beginnen scanners met het raden van gebruikersnamen en wachtwoorden op port 22. U kunt dit binnen enkele minuten in uw logs waarnemen. SSH hardening houdt in dat u elementen verwijdert die geraden kunnen worden: schakel wachtwoord-login volledig uit, schakel root-login uit, en staat alleen cryptografische keys toe. Zodra u dit heeft ingesteld, kunnen brute-force pogingen niet slagen, omdat er geen wachtwoord meer te vinden is.

Dit gaat ervan uit dat SSH al functioneert. Als u kunt inloggen, kunt u de beveiliging verhogen. Voer de stappen in de juiste volgorde uit. Houd uw huidige sessie open totdat een nieuwe sessie werkt, zodat u zichzelf nooit per ongeluk uitsluit van toegang.

Stap 1: Controleer eerst of de sleutelauthenticatie werkt

Sleutelauthenticatie vervangt een wachtwoord door een sleutelpaar: een private key die op uw computer blijft staan en een public key die u op de server plaatst. De server stelt vast dat u de private key bezit zonder dat deze uw machine verlaat. Controleer of de sleutels werken voordat u wachtwoorden uitschakelt, anders kunt u uzelf buitensluiten.

Maak op uw eigen computer een sleutel aan als u deze nog niet heeft:

ssh-keygen -t ed25519

Kopieer de public key naar de server:

ssh-copy-id user@your-server

Open vervolgens een nieuwe SSH-sessie. Als u kunt inloggen zonder om een wachtwoord te vragen, werkt uw sleutel en kunt u wachtwoorden veilig uitschakelen. Als u nieuw bent in het gebruik van sleutels, of als u meer dan één computer gebruikt, legt SSH key management basics het volledige model uit: één sleutel per apparaat, de rechten die sshd vereist, en hoe u een sleutel intrekt als een laptop wordt gestolen.

Stap 2: Harden sshd met een drop-in file

Wijzig /etc/ssh/sshd_config niet rechtstreeks. Ubuntu 24.04 leest drop-in files uit /etc/ssh/sshd_config.d/. Een klein bestand in deze map is overzichtelijker, blijft behouden tijdens package upgrades en is eenvoudig te verwijderen als er problemen ontstaan. De bestandsnaam is cruciaal: sshd gebruikt de eerste waarde die wordt gelezen voor elke instelling. Ubuntu cloud images bevatten 50-cloud-init.conf met PasswordAuthentication yes in deze directory. Geef uw bestand de naam 00- zodat het voor het andere bestand wordt gesorteerd en de instelling wint; een 99- bestand wordt stilzwijgend genegeerd. Maak een bestand aan:

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

Plaats dit in:

# 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: als wachtwoorden uitgeschakeld zijn, heeft een brute-force aanval geen doelwit meer. KbdInteractiveAuthentication no sluit een tweede wachtwoord-gebaseerd pad. PermitRootLogin no betekent dat een aanvaller zowel uw gebruikersnaam moet kennen als uw key moet bezitten. Men kan dan niet langer simpelweg mikken op het standaard account, root, dat op elke machine bestaat.

Stap 3: De configuratie testen en herladen

Controleer de configuratie op fouten voordat u deze toepast. Dit voorkomt dat een typefout de service onderbreekt:

sudo sshd -t

Als er geen output wordt getoond, is de configuratie geldig. Herlaad SSH:

sudo systemctl reload ssh

Controleer vervolgens de instellingen die sshd daadwerkelijk gebruikt. Zo detecteert u configuratiebestanden die worden overschreven door andere bestanden:

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

Beide moeten no aangeven. Open nu, zonder uw huidige sessie te sluiten, een nieuwe sessie via een andere terminal. Als u wordt ingelogd met uw sleutel, is de taak voltooid. Als er iets misgaat, blijft uw eerste sessie openstaan om het te herstellen. Deze overlap dient als veiligheidsnet; sla deze stap nooit over.

Stap 4: De optionele niet-standaard poort

Het verplaatsen van SSH van poort 22 naar bijvoorbeeld 2222 vergroot de beveiliging niet in de praktijk. Een vastberaden aanvaller scant namelijk alle poorten. Het voordeel is dat de hoeveelheid ruis in de logs afneemt, omdat de meeste automatische scanners alleen poort 22 proberen. Als u dit wilt, voeg dan Port 2222 toe aan uw drop-in file. Sta de nieuwe poort eerst toe in de firewall, voer vervolgens 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 luisterpoort. Een standaard reload ssh laat sshd op poort 22 staan; het herstarten van de socket zorgt ervoor dat de nieuwe poort wordt geactiveerd. Beschouw dit als een manier om de configuratie overzichtelijk te houden, niet als beveiliging.

Stap 5: Voeg extra beveiligingslagen toe

Hardened SSH-keys vormen de basis. Er volgen nog twee extra beveiligingslagen.

Fail2ban controleert uw logs en blokkeert adressen die herhaaldelijk falen. Dit vermindert de ruis van scanners en blokkeert deze vroegtijdig. Het werkt goed in combinatie met authenticatie via alleen keys: zie Fail2ban op Ubuntu om SSH-aanvallen te stoppen.

Nog effectiever is het volledig weghalen van SSH van het publieke internet. Als u SSH achter een WireGuard VPN plaatst en poort 22 beperkt tot de tunnel, is de verbinding onbereikbaar voor iedereen buiten de VPN. Brute-force aanvallen worden hierdoor onmogelijk in plaats van alleen moeilijk. Dit vereist een firewall met een default-deny instelling, zoals UFW op de VPS.

SSH is slechts één onderdeel van een grotere 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.

FAQ

Hoe schakel ik wachtwoordlogin voor SSH uit op Ubuntu 24.04?

Maak een drop-in bestand aan op /etc/ssh/sshd_config.d/00-hardening.conf (de 00 prefix zorgt dat dit bestand vóór 50-cloud-init.conf wordt gesorteerd, anders wint de PasswordAuthentication yes van dat bestand, omdat sshd de eerste waarde die wordt gelezen gebruikt) met PasswordAuthentication no en KbdInteractiveAuthentication no. Voer sudo sshd -t uit om de configuratie te controleren en voer daarna sudo systemctl reload ssh uit. Controleer of de login met een sleutel werkt in een nieuwe sessie voordat u de oude sessie sluit. Het aanpassen van een drop-in bestand in plaats van sshd_config blijft behouden tijdens 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 administratieve taken. Root bestaat op elke Linux-machine, dus als deze bereikbaar blijft, heeft een aanvaller een bekende gebruikersnaam om te targeten. Het uitschakelen hiervan betekent dat een aanvaller uw accountnaam moet weten en uw sleutel moet bezitten.

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

Niet significant. Het verplaatsen vanaf poort 22 verbergt u voor luie scanners die alleen poort 22 controleren. Dit vermindert de ruis in de logs, maar een echte aanvaller scant alle poorten en vindt de poort alsnog. Alleen authenticatie met sleutels voorkomt daadwerkelijk inbraken. Als u de poort wijzigt, moet u eerst de nieuwe poort openen in de firewall en daarna sudo systemctl daemon-reload && sudo systemctl restart ssh.socket uitvoeren; op Ubuntu 24.04 beheert de socket de listener, waardoor een gewone reload sshd op poort 22 laat draaien.

Heb ik Fail2ban nodig als ik SSH-sleutels gebruik?

Dit is optioneel maar nog steeds nuttig. Bij authenticatie met alleen sleutels kan het raden van wachtwoorden niet slagen, dus Fail2ban is niet wat aanvallers buiten de deur houdt. Het beperkt het aantal herhaalde mislukte pogingen vanaf één adres, wat de ruis van scanners in uw logs vermindert en recidivisten vroegtijdig blokkeert; een trage, gedistribueerde aanval blijft sowieso onder de ban-drempel. Gebruik het naast sleutel-authenticatie en houd SSH bij voorkeur achter een VPN.

Hoe herstel ik als ik mezelf uitsluit van SSH?

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