Authenticatielogboeken van een nieuwe VPS: 200 root / admin123 pogingen in vier uur - robots, geen persoonlijk doelwit. De server valt niet uit vanwege zero-day SSH, maar omdat Wachtwoordauthenticatie ja na de installatie nog steeds aanwezig was. Vier gewoonten zouden 95% van dit oppervlak hebben afgesloten.
SSH is de beheerdeur van uw VPS. Bij een klein project is dit vaak het enige. Voor het beveiligen ervan is geen beveiligingscentrum nodig; er is basisdiscipline voor nodig.
Automatische scans richten zich te allen tijde op mondiale poort 22. Het goede nieuws: ze zijn op zoek naar standaardwaarden: rootwachtwoorden, zwakke sleutels, verouderde services. Vier goed toegepaste gewoonten verkleinen het oppervlak drastisch zonder exotisch gereedschap. Koppel ze met VPS firewall en regelmatige updates.
Gewoonte 1: Alleen sleutelverificatie
Genereer lokaal een Ed25519-sleutel, implementeer de openbare sleutel in ~/.ssh/authorized_keys voor een specifieke gebruiker. In /etc/ssh/sshd_config stelt u PasswordAuthentication no, PubkeyAuthentication yes, PermitRootLogin no in. Test een nieuwe sessie voordat u de oude sluit en laad vervolgens sshd opnieuw.
Een sleutel zonder wachtwoord op een gestolen laptop = hoofdsleutel. Wachtwoordzin of hardwaretoken voor productie.
Gewoonte 2: niet-rootgebruiker plus sudo
Maak 'deploy' of 'admin' aan in de sudo-groep. Direct rooten verboden; bewerkingen via sudo ingelogd. Schakel demo-accounts voor cloudimages uit.
Gewoonte 3: fail2ban (of gelijkwaardig)
Gevangenis sshd — verbied het IP-adres na N fouten. Koppel met firewall beperkend. Office IP-witte lijst, indien opgelost. Vertrouw niet alleen op het wijzigen van poort 22; de scans bestrijken het hele bereik.
Gewoonte 4: bijwerken en minimale oppervlakte
Automatische beveiligingsoplossingen (onbeheerde upgrades). Verwijder onnodige services die luisteren. MaxAuthTries 3, AllowUsers geïmplementeerd als klein team.
Bastion- en teamtoegang
Multi-server: één bastion SSH (beperkt IP-adres) of WireGuard VPN; productie niet blootgesteld openbare SSH indien mogelijk. Verschillende staging/productiesleutels. Sleutels intrekken na vertrek van werknemer: implementatiegeheimen bevat CI SSH-sleutels.
| Slecht | Beter |
|---|---|
| root + wachtwoord | gebruiker + sleutel + sudo |
| overal dezelfde sleutel | sleutels per omgeving |
| SSH-wereld 0.0.0.0/0 | IP-beheerdersfirewall |
Beyond SSH: vergeet de applicatie niet
Het versterken van SSH is geen vervanging voor het patchen van WordPress, het sluiten van blootgestelde phpMyAdmin of het verwijderen van .env uit de repository — zie deployment secrets. Veel kleine VPS-compromissen ontstaan door het lekken van applicaties of inloggegevens na succesvolle SSH-hardening. De vier gewoonten blijven noodzakelijk; ze zijn niet genoeg alleen.
De bovenkant: gehard SSH beschermt de applicatie niet
Beslis en ga vooruit zonder blinde vlek
Genereer de Ed25519-sleutel met wachtwoordzin. Maak een sudo-gebruiker en test de sleutelaanmelding. Schakel wachtwoordverificatie en SSH-rootaanmelding uit. Schakel fail2ban en firewall in die poort 22 beperkt. Toegang tot noodconsole documenteren. Vergelijk hosts met console-redding via de overzicht.
Veelgestelde vragen
RSA-sleutel of Ed25519?
Ed25519 is aan te raden voor een nieuwe VPS: short key, modern en snel inzetbaar. RSA 4096 is nog steeds acceptabel als u een oudere omgeving moet ondersteunen. Op een laptop beschermt u de privésleutel met een wachtwoordzin, of met een vergrendelde SSH-agent bij het afmelden.
Root SSH volledig uitschakelen?
Ja, zodra een sudo-gebruiker is aangemaakt en getest vanuit een nieuwe parallelle sessie. Houd de hostconsole (KVM of serieel) toegankelijk: een fout in sshd_config kan u uitsluiten vóór de volgende implementatie. Test de sleutelaanmelding voordat u de rootsessie sluit.
is fail2ban genoeg?
Niet alleen. fail2ban vormt een aanvulling op het uitschakelen van sleutels en wachtwoorden door IP-adressen te verbieden na herhaalde fouten. Stel de duur van de ban in en zet het vaste IP-adres van het kantoor op de witte lijst als u die heeft, anders loopt u het risico geblokkeerd te worden na uw eigen tests.
SSH op meerdere servers: hoe organiseren?
Gebruik aparte sleutels per omgeving (staging, productie), een Host blok in ~/.ssh/config per server, en een bastion of WireGuard VPN voor productie. Beperk poort 22 via VPS firewall tot geautoriseerde beheerdersadressen; de sleutels intrekken als een medewerker vertrekt.
Veilige SSH: vier voor de hand liggende gewoonten (sleutels, geen root-wachtwoord, sudo, fail2ban) die te veel VPS pas na de eerste succesvolle scan afdwingen.