SSH Beveiliging 20 min leestijd

SSH Hardening op Linux in 2026: Post-Quantum Cryptografie, Certificaten en Geavanceerde Beveiliging

Leer hoe je SSH op Linux volledig beveiligt in 2026. Van post-quantum algoritmen in OpenSSH 10.0 en certificaatauthenticatie tot Fail2Ban, MFA en monitoring — een praktische gids met configuratievoorbeelden.

Editorial Team

Introductie: SSH in het Tijdperk van Quantumcomputers

SSH is de ruggengraat van vrijwel elke Linux-omgeving. Of je nu een handvol servers beheert of duizenden containers orkestreert — SSH is hoe je inlogt, configuraties uitrolt en problemen oplost. Maar de wereld staat niet stil. OpenSSH 10.0, uitgebracht in april 2025, markeert een echt keerpunt: post-quantumcryptografie is nu de standaard, DSA-ondersteuning is compleet verdwenen, en de architectuur van de SSH-daemon is fundamenteel herzien om het aanvalsoppervlak te verkleinen.

De cijfers liegen er niet om. Volgens het Elastic Global Threat Report is 89% van alle aanvalsgedrag op Linux-endpoints gerelateerd aan brute-force aanvallen — en SSH is daarbij veruit het populairste doelwit. In Q4 2025 was de P2PInfect-worm verantwoordelijk voor maar liefst 80,4% van alle aanvallen op Linux SSH-servers, zo blijkt uit honeypotdata van AhnLab. Eerlijk gezegd schokte dat cijfer me toen ik het voor het eerst las. Ondanks alle vooruitgang in authenticatiemethoden blijven aanvallers onvermoeibaar zwakke SSH-configuraties opzoeken en misbruiken.

In deze gids neem ik je stap voor stap mee door het volledige proces van SSH-hardening in 2026. Van de nieuwste post-quantumalgoritmen en certificaatgebaseerde authenticatie tot geavanceerde monitoringtechnieken — met praktische configuratievoorbeelden die je direct kunt toepassen. Of je nu een doorgewinterde systeembeheerder bent of net begint met Linux-beveiliging: na dit artikel heb je een robuuste, toekomstbestendige SSH-setup.

Wat is er Nieuw in OpenSSH 10.0?

Voordat we in de hardening duiken, is het belangrijk om te begrijpen wat OpenSSH 10.0 anders doet dan zijn voorgangers. Deze versie bevat de meest ingrijpende wijzigingen in jaren — en dat is niet overdreven.

Post-Quantum Key Exchange als Standaard

De grootste verandering is dat het hybride post-quantumalgoritme mlkem768x25519-sha256 nu standaard wordt gebruikt voor key exchange. Dit algoritme combineert het NIST-gestandaardiseerde ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) met het beproefde Curve25519. Het resultaat? Een key exchange die bestand is tegen zowel klassieke aanvallen als toekomstige aanvallen door quantumcomputers.

Waarom is dit zo belangrijk? Quantumcomputers die krachtig genoeg zijn om huidige cryptografie te breken bestaan op dit moment nog niet. Maar het risico van "harvest now, decrypt later"-aanvallen is zeer reëel: aanvallers kunnen vandaag versleuteld SSH-verkeer opvangen en opslaan, om het later te ontsleutelen wanneer quantumcomputers beschikbaar zijn. Dat klinkt misschien als sciencefiction, maar inlichtingendiensten doen dit nu al. Door nu post-quantumalgoritmen te gebruiken, bescherm je het verkeer van vandaag tegen de dreigingen van morgen.

Het eerdere standaardalgoritme sntrup761x25519-sha512 (beschikbaar sinds OpenSSH 9.0) wordt nog steeds ondersteund, maar is niet langer de standaard. Vanaf OpenSSH 10.1 verschijnt er zelfs een waarschuwing wanneer een niet-post-quantum key exchange wordt gebruikt — tenzij je dit expliciet uitschakelt via de WarnWeakCrypto-optie.

Volledige Verwijdering van DSA

DSA (Digital Signature Algorithm) was al sinds 2015 standaard uitgeschakeld in OpenSSH, maar bleef beschikbaar als optie. In OpenSSH 10.0 is DSA-ondersteuning volledig verwijderd. Dat betekent dat servers die nog DSA-sleutels gebruiken na een upgrade simpelweg niet meer bereikbaar zijn via die sleutels. Controleer dit dus vóór je upgrade:

# Controleer of er nog DSA-hostsleutels aanwezig zijn
ls -la /etc/ssh/ssh_host_dsa_key*

# Controleer of gebruikers nog DSA-sleutels gebruiken
grep -r "ssh-dss" /home/*/.ssh/authorized_keys 2>/dev/null

# Als er DSA-sleutels gevonden worden, genereer Ed25519-sleutels als vervanging
ssh-keygen -t ed25519 -C "gebruiker@hostname" -f ~/.ssh/id_ed25519

De Nieuwe sshd-auth Binary

Een architecturale verbetering die bijzonder relevant is voor beveiliging: de pre-authenticatiecode is verplaatst naar een aparte binary genaamd sshd-auth. Voorheen draaide alles — zowel pre- als post-authenticatie — binnen hetzelfde proces. Een kwetsbaarheid in de pre-authenticatiefase kon dus potentieel toegang geven tot de volledige adresruimte van het sshd-proces. Niet ideaal, om het zacht uit te drukken.

Door de pre-authenticatiecode te isoleren in een eigen binary met een volledig gescheiden adresruimte, wordt het aanvalsoppervlak drastisch verkleind. Zodra de authenticatie is voltooid wordt de sshd-auth binary uit het geheugen verwijderd — wat ook een klein geheugenvoordeel oplevert. Op OpenBSD wordt sshd-auth bovendien bij elke boot willekeurig opnieuw gelinkt, wat exploitatie nog verder bemoeilijkt.

Vervanging van Diffie-Hellman door ECDH

OpenSSH 10.0 schakelt de oudere finite-field Diffie-Hellman (modp) key exchange methoden standaard uit op de server. Elliptic Curve Diffie-Hellman (ECDH) is nu de norm. De modp-methoden zijn kwetsbaarder voor aanvallen en bieden geen post-quantumgaranties. Heb je nog systemen die uitsluitend modp ondersteunen? Dan moeten die dringend worden geüpgraded.

Recente Kwetsbaarheden: CVE-2025-26465 en CVE-2025-26466

Voordat we de hardening-configuratie bespreken, wil ik twee kritieke kwetsbaarheden benoemen die in februari 2025 zijn gepatcht in OpenSSH 9.9p2. Kennis van recente kwetsbaarheden helpt je te begrijpen waarom bepaalde configuratiekeuzes zo belangrijk zijn.

CVE-2025-26465: Man-in-the-Middle Aanval

Deze kwetsbaarheid trof ssh(1) in OpenSSH versies 6.8p1 tot en met 9.9p1. Een logische fout maakte het mogelijk voor een on-path aanvaller om elke server te imiteren wanneer de VerifyHostKeyDNS-optie was ingeschakeld. Hoewel deze optie standaard uitgeschakeld is, zijn er organisaties die haar bewust inschakelen voor SSHFP-verificatie via DNS. Check of jouw configuratie kwetsbaar is:

# Controleer of VerifyHostKeyDNS is ingeschakeld
grep -i "VerifyHostKeyDNS" /etc/ssh/ssh_config ~/.ssh/config 2>/dev/null

# Als het is ingeschakeld en je draait een versie ouder dan 9.9p2:
ssh -V
# Upgrade onmiddellijk als je versie ouder is dan 9.9p2

CVE-2025-26466: Pre-Authenticatie Denial of Service

Deze kwetsbaarheid maakte pre-authenticatie DoS-aanvallen mogelijk door overmatig geheugen- en CPU-verbruik te veroorzaken. Herhaalde exploitatie kon serverbeheer verstoren en legitieme gebruikers buitensluiten. De patch in 9.9p2 introduceert rate-limiting en resourcebeperkingen om dit soort aanvallen te mitigeren.

De les? Houd je OpenSSH-installatie altijd up-to-date. De allereerste stap in SSH-hardening is simpelweg het draaien van de nieuwste versie.

Complete sshd_config Hardening

Goed, nu we de context kennen, gaan we aan de slag met een complete geharde SSH-serverconfiguratie. Ik loop elk onderdeel stap voor stap met je door.

Basisbeveiliging: Authenticatie en Toegang

# /etc/ssh/sshd_config — Basisbeveiliging

# Gebruik uitsluitend SSH protocol versie 2
Protocol 2

# Luister op een niet-standaard poort (optioneel maar vermindert geautomatiseerde scans)
Port 2222

# Bind alleen aan specifieke interfaces als de server meerdere netwerkkaarten heeft
ListenAddress 10.0.1.50

# Schakel root-login volledig uit
PermitRootLogin no

# Sta alleen specifieke gebruikers toe
AllowUsers deployer sysadmin
# Of gebruik groepen voor betere schaalbaarheid
# AllowGroups ssh-users ssh-admins

# Schakel wachtwoordauthenticatie volledig uit
PasswordAuthentication no

# Schakel challenge-response authenticatie uit (tenzij je PAM/TOTP gebruikt)
KbdInteractiveAuthentication no

# Schakel lege wachtwoorden uit
PermitEmptyPasswords no

# Beperk het aantal authenticatiepogingen
MaxAuthTries 3

# Stel het maximale aantal gelijktijdige ongeauthenticeerde verbindingen in
MaxStartups 10:30:60

# Stel een login-graceperiode in (tijd om te authenticeren)
LoginGraceTime 30

Laat me een paar keuzes toelichten. Het veranderen van de poort (hier naar 2222) is geen echte beveiligingsmaatregel — het is security through obscurity. Maar eerlijk? Het scheelt enorm in het aantal geautomatiseerde brute-force pogingen, wat je logs schoner houdt en de belasting op je server verlaagt. Combineer het alleen altijd met echte beveiligingsmaatregelen.

De MaxStartups 10:30:60 instelling verdient wat extra uitleg: het eerste getal (10) is het aantal ongeauthenticeerde verbindingen waarna rate-limiting begint. Het tweede getal (30) is het percentage kans dat een nieuwe verbinding wordt geweigerd. Het derde getal (60) is het aantal verbindingen waarna alles wordt geweigerd. Dit beschermt effectief tegen de DoS-aanval die ik eerder beschreef bij CVE-2025-26466.

Post-Quantum Cryptografische Instellingen

# /etc/ssh/sshd_config — Cryptografische hardening voor 2026

# Key Exchange Algoritmen — post-quantum eerst
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

# Ciphers — prioriteer AES-256 voor quantumbestendigheid
Ciphers [email protected],[email protected],aes256-ctr,aes192-ctr

# MACs — prioriteer SHA-512 voor grotere hashlengte
MACs [email protected],[email protected]

# Hostsleutelalgoritmen — Ed25519 en RSA (minimaal 4096-bit)
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Specificeer de hostsleutels
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

De volgorde is hier cruciaal: het eerste algoritme in de lijst krijgt de voorkeur. Door mlkem768x25519-sha256 bovenaan te zetten, zorg je ervoor dat clients die post-quantum ondersteunen hier automatisch voor kiezen. Clients die het niet ondersteunen vallen terug op Curve25519 — nog steeds veilig tegen klassieke aanvallen.

Waarom AES-256 boven ChaCha20? Hoewel ChaCha20-Poly1305 uitstekend presteert op systemen zonder AES-NI hardware-instructies, biedt AES-256 een grotere sleutellengte die meer weerstand biedt tegen quantumaanvallen. Op moderne servers met AES-NI is AES-256-GCM bovendien sneller. In de praktijk merk je daar als gebruiker niets van, maar op schaal telt het wel.

Sessiebeheer en Hardening

# /etc/ssh/sshd_config — Sessiebeheer

# Schakel X11 forwarding uit (tenzij expliciet nodig)
X11Forwarding no

# Schakel TCP forwarding uit voor niet-beheerders
AllowTcpForwarding no

# Schakel agent forwarding uit
AllowAgentForwarding no

# Schakel tunneling uit
PermitTunnel no

# Voorkom dat gebruikers omgevingsvariabelen instellen
PermitUserEnvironment no

# Gebruik een strikt scheidingsmodel
StrictModes yes

# Stel idle-timeouts in om vergeten sessies automatisch te sluiten
ClientAliveInterval 300
ClientAliveCountMax 2

# Log alles op INFO-niveau (of hoger voor debugging)
LogLevel VERBOSE

# Toon een waarschuwingsbanner
Banner /etc/ssh/banner.txt

# Schakel .rhosts-bestanden uit
IgnoreRhosts yes

# Schakel host-based authenticatie uit
HostbasedAuthentication no

De ClientAliveInterval en ClientAliveCountMax werken als team: elke 300 seconden (5 minuten) stuurt de server een keep-alive bericht. Na 2 gemiste berichten wordt de sessie beëindigd. Dat betekent dat een inactieve sessie na maximaal 10 minuten automatisch wordt gesloten — essentieel voor het beperken van het risico van achtergelaten sessies. (We kennen het allemaal: even snel koffie halen die uitloopt tot een vergadering van een uur.)

Het instellen van LogLevel VERBOSE is belangrijk voor forensisch onderzoek. Op dit niveau logt OpenSSH onder andere welk sleuteltype en welke key fingerprint is gebruikt bij authenticatie — onmisbaar wanneer je een incident onderzoekt.

Hostsleutels Correct Genereren

Een veelgemaakte fout bij het opzetten van SSH-servers is het gebruik van automatisch gegenereerde hostsleutels zonder de kwaliteit te controleren. Ik heb het in de praktijk vaker zien misgaan dan je zou verwachten. Hier is het juiste proces:

# Verwijder bestaande hostsleutels
sudo rm /etc/ssh/ssh_host_*

# Genereer een nieuwe Ed25519-hostsleutel (aanbevolen)
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Genereer een nieuwe RSA-hostsleutel met 4096-bit sleutellengte
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

# Stel de juiste bestandsrechten in
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub

# Controleer de fingerprints van de nieuwe sleutels
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

Bewaar die fingerprints op een veilige locatie. Wanneer collega's voor het eerst verbinding maken met de server, moeten ze deze fingerprint kunnen verifiëren om man-in-the-middle aanvallen te voorkomen.

RSA-sleutellengte: 4096 of meer?

De keuze voor 4096-bit RSA in plaats van het veelgebruikte 2048-bit is een bewuste afweging. Hoewel 2048-bit RSA op dit moment nog veilig wordt geacht tegen klassieke aanvallen, biedt 4096-bit een grotere marge tegen toekomstige kwantumgerelateerde ontwikkelingen. Het prestatieverschil is op moderne hardware verwaarloosbaar. Maar voor nieuwe implementaties in 2026 is Ed25519 simpelweg de betere keuze vanwege superieure prestaties en inherente beveiliging.

SSH-Certificaatauthenticatie: Voorbij Sleutels

Traditionele SSH-sleutelauthenticatie heeft een fundamenteel schaalbaarheidsprobleeem: voor elke gebruiker op elke server moet een publieke sleutel worden geïnstalleerd in het authorized_keys-bestand. Bij honderden servers en tientallen gebruikers wordt dit al snel een nachtmerrie. SSH-certificaatauthenticatie lost dit elegant op door een Certificate Authority (CA) te introduceren die certificaten ondertekent.

De Certificate Authority Opzetten

# Maak een directory voor de CA
sudo mkdir -p /etc/ssh/ca
sudo chmod 700 /etc/ssh/ca

# Genereer de User CA-sleutel (voor gebruikerscertificaten)
sudo ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA"

# Genereer de Host CA-sleutel (voor hostcertificaten)
sudo ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "SSH Host CA"

# BELANGRIJK: Bewaar de privésleutels op een geïsoleerd systeem
# De CA-sleutels zijn het meest gevoelige onderdeel van je SSH-infrastructuur

Het gebruik van twee aparte CA's — één voor gebruikers en één voor hosts — is een essentiële best practice. Wordt de User CA gecompromitteerd, dan hoef je alleen gebruikerscertificaten te herroepen, niet de hostcertificaten (en andersom). Dat beperkt de schade van een beveiligingsincident behoorlijk.

Hostcertificaten Uitgeven

# Onderteken de hostsleutel met de Host CA
sudo ssh-keygen -s /etc/ssh/ca/host_ca \
  -I "webserver01.example.nl" \
  -h \
  -n "webserver01.example.nl,webserver01,10.0.1.50" \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

# Resultaat: /etc/ssh/ssh_host_ed25519_key-cert.pub

# Configureer sshd om het hostcertificaat te gebruiken
# Voeg toe aan /etc/ssh/sshd_config:
# HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# Verifieer het certificaat
ssh-keygen -Lf /etc/ssh/ssh_host_ed25519_key-cert.pub

De -V +52w parameter stelt de geldigheid in op 52 weken (1 jaar). Voor hostcertificaten is een langere geldigheid prima, omdat het heruitgeven operationeel lastig kan zijn. Voor gebruikerscertificaten raad ik echter kortere periodes aan — daar kom ik zo op terug.

Gebruikerscertificaten Uitgeven

# Gebruiker genereert een sleutelpaar (als dat nog niet bestaat)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "[email protected]"

# De gebruiker stuurt de PUBLIEKE sleutel naar de CA-beheerder
# De CA-beheerder ondertekent het certificaat:
sudo ssh-keygen -s /etc/ssh/ca/user_ca \
  -I "[email protected]" \
  -n "jan,deployer" \
  -V +8h \
  -O source-address=10.0.0.0/16 \
  ~/.ssh/id_ed25519.pub

# Resultaat: ~/.ssh/id_ed25519-cert.pub (terugsturen naar gebruiker)

# De gebruiker kan het certificaat inspecteren
ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub

Let op de parameters: -V +8h geeft het certificaat een geldigheid van slechts 8 uur — ideaal voor werkdaggebruik. De gebruiker moet dagelijks een nieuw certificaat aanvragen, wat het risico van gestolen certificaten fors beperkt. En de -O source-address=10.0.0.0/16 optie beperkt het gebruik tot verbindingen vanuit het opgegeven IP-bereik. Dubbele beveiliging, dus.

Server Configureren voor Certificaatauthenticatie

# Voeg toe aan /etc/ssh/sshd_config:

# Vertrouw de User CA voor gebruikersauthenticatie
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# Gebruik het hostcertificaat
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# Optioneel: schakel traditionele sleutelauthenticatie uit
# PubkeyAuthentication no
# AuthorizedKeysFile none

# Herstart sshd om de wijzigingen toe te passen
sudo systemctl restart sshd

Clientconfiguratie voor Hostverificatie via CA

# Voeg toe aan ~/.ssh/known_hosts of /etc/ssh/ssh_known_hosts:
@cert-authority *.example.nl ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... "SSH Host CA"

# Hiermee vertrouwt de client automatisch alle hosts met een certificaat
# ondertekend door de Host CA — geen handmatige fingerprint-verificatie meer nodig

Dit is het punt waarop certificaatauthenticatie echt gaat schitteren: nieuwe servers worden automatisch vertrouwd zolang ze een geldig certificaat hebben. Geen "Are you sure you want to continue connecting?" meer bij elke nieuwe server. Als je ooit tientallen servers hebt moeten uitrollen, weet je hoe prettig dat is.

Multi-Factor Authenticatie met TOTP

Voor omgevingen waar een extra beveiligingslaag gewenst is — denk aan bastion hosts of jump servers — kun je SSH combineren met Time-based One-Time Passwords (TOTP) via Google Authenticator PAM. Persoonlijk vind ik dit een must-have voor iedere bastion host.

Installatie en Configuratie

# Installeer de Google Authenticator PAM-module
# Debian/Ubuntu:
sudo apt install libpam-google-authenticator

# RHEL/Fedora/AlmaLinux:
sudo dnf install google-authenticator

# Configureer TOTP voor de huidige gebruiker
google-authenticator -t -d -f -r 3 -R 30 -w 3 -Q UTF8

# Parameters:
# -t : Gebruik tijdgebaseerde tokens
# -d : Sta geen hergebruik van tokens toe
# -f : Schrijf configuratie naar ~/.google_authenticator
# -r 3 -R 30 : Maximaal 3 pogingen per 30 seconden
# -w 3 : Sta tokens tot 3 stappen (90 seconden) afwijking toe
# -Q UTF8 : Toon QR-code in terminal (scan met authenticator-app)

PAM Configureren

# Bewerk /etc/pam.d/sshd
# Voeg toe na de bestaande regels:
auth required pam_google_authenticator.so nullok

# De 'nullok' optie staat gebruikers die TOTP nog niet hebben geconfigureerd
# tijdelijk toe om in te loggen zonder code. Verwijder 'nullok' zodra alle
# gebruikers zijn geconfigureerd.

sshd_config Aanpassen voor MFA

# Voeg toe aan /etc/ssh/sshd_config:

# Vereist zowel publickey als keyboard-interactive (TOTP)
AuthenticationMethods publickey,keyboard-interactive

# Schakel keyboard-interactive authenticatie in voor TOTP
KbdInteractiveAuthentication yes

# Schakel PAM in
UsePAM yes

# Herstart sshd
sudo systemctl restart sshd

Met deze configuratie moeten gebruikers eerst hun SSH-sleutel presenteren en vervolgens een TOTP-code invoeren. Dit is echte multi-factor authenticatie: iets dat je hebt (de privésleutel) en iets dat je weet (de TOTP-code, die elke 30 seconden verandert). Simpel maar effectief.

Brute-Force Bescherming met Fail2Ban

Ondanks het uitschakelen van wachtwoordauthenticatie is brute-force bescherming nog steeds waardevol. Aanvallers die herhaaldelijk authenticatiepogingen doen verbruiken serverresources en vervuilen je logs. Fail2Ban bewaakt je logbestanden en blokkeert tijdelijk IP-adressen die verdacht gedrag vertonen.

Installatie en SSH Jail Configuratie

# Installeer Fail2Ban
# Debian/Ubuntu:
sudo apt install fail2ban

# RHEL/Fedora/AlmaLinux:
sudo dnf install fail2ban

# Maak een lokaal configuratiebestand (wordt niet overschreven bij updates)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# /etc/fail2ban/jail.local — SSH-specifieke configuratie

[DEFAULT]
# Ban-tijd: 1 uur
bantime = 3600

# Zoekvenster: 10 minuten
findtime = 600

# Maximaal aantal pogingen voordat een IP wordt geblokkeerd
maxretry = 3

# E-mailnotificatie bij bans (optioneel)
# destemail = [email protected]
# sender = [email protected]
# action = %(action_mwl)s

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
# Op RHEL/CentOS/AlmaLinux: logpath = /var/log/secure
maxretry = 3
bantime = 3600

# Agressieve modus: ban ook bij ongeldige gebruikersnamen
mode = aggressive

# Recidive-jail: langere ban voor herhaalde overtreders
[recidive]
enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
bantime = 604800
findtime = 86400
maxretry = 3
# Start en activeer Fail2Ban
sudo systemctl enable --now fail2ban

# Controleer de status van de SSH-jail
sudo fail2ban-client status sshd

# Voorbeeld uitvoer:
# Status for the jail: sshd
# |- Filter
# |  |- Currently failed: 2
# |  |- Total failed:     847
# |  `- File list:        /var/log/auth.log
# `- Actions
#    |- Currently banned: 5
#    |- Total banned:     312
#    `- Banned IP list:   203.0.113.50 198.51.100.23 ...

# Handmatig een IP deblokkeren
sudo fail2ban-client set sshd unbanip 203.0.113.50

De recidive-jail is een bijzonder krachtige toevoeging: IP-adressen die herhaaldelijk worden geblokkeerd en toch terugkomen, worden voor een hele week geblokkeerd. In mijn ervaring is dit bijzonder effectief tegen hardnekkige botnets die steeds met dezelfde IP-reeksen terugkeren.

Geavanceerde Monitoring en Logging

Een geharde SSH-configuratie is slechts de helft van het verhaal. Zonder adequate monitoring kun je niet detecteren of iemand je beveiliging probeert te omzeilen. Hier zijn de technieken die ik aanbeveel voor productieomgevingen.

Gestructureerd Loggen met Journald

# Bekijk SSH-gerelateerde logs in realtime
sudo journalctl -u sshd -f

# Filter op mislukte authenticatiepogingen
sudo journalctl -u sshd | grep -i "failed\|invalid\|refused"

# Bekijk succesvolle logins van de afgelopen 24 uur
sudo journalctl -u sshd --since "24 hours ago" | grep "Accepted"

# Exporteer logs in JSON-formaat voor analyse
sudo journalctl -u sshd -o json --since "2026-02-01" > ssh_logs.json

Auditd voor SSH-Activiteiten

Voor organisaties die moeten voldoen aan compliance-eisen zoals ISO 27001 of de NIS2-richtlijn is het Linux Audit Framework (auditd) onmisbaar:

# Installeer auditd (vaak al geïnstalleerd)
# Debian/Ubuntu:
sudo apt install auditd

# Voeg SSH-specifieke auditregels toe
sudo cat >> /etc/audit/rules.d/ssh.rules << 'EOF'
# Monitor wijzigingen aan sshd_config
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

# Monitor wijzigingen aan authorized_keys bestanden
-w /home/ -p wa -k ssh_authorized_keys

# Monitor SSH-sleutelbestanden
-w /etc/ssh/ -p wa -k ssh_host_keys

# Monitor de sshd binary
-w /usr/sbin/sshd -p x -k sshd_execution

# Monitor su en sudo gebruik na SSH-login
-w /usr/bin/su -p x -k privilege_escalation
-w /usr/bin/sudo -p x -k privilege_escalation
EOF

# Herlaad auditregels
sudo augenrules --load

# Zoek naar SSH-gerelateerde auditgebeurtenissen
sudo ausearch -k sshd_config_change -ts recent

Automatische Waarschuwingen met een Monitoring Script

#!/bin/bash
# /usr/local/bin/ssh-monitor.sh
# Detecteert en rapporteert verdachte SSH-activiteit

LOG_FILE="/var/log/auth.log"
ALERT_THRESHOLD=10
ADMIN_EMAIL="[email protected]"

# Tel mislukte pogingen per IP in het afgelopen uur
declare -A failed_ips

while IFS= read -r line; do
    ip=$(echo "$line" | grep -oP 'from \K[0-9.]+')
    if [[ -n "$ip" ]]; then
        ((failed_ips[$ip]++))
    fi
done < <(journalctl -u sshd --since "1 hour ago" | grep "Failed")

# Rapporteer IPs boven de drempelwaarde
for ip in "${!failed_ips[@]}"; do
    count=${failed_ips[$ip]}
    if (( count >= ALERT_THRESHOLD )); then
        echo "[WAARSCHUWING] IP $ip had $count mislukte SSH-pogingen in het afgelopen uur" | \
            logger -t ssh-monitor -p auth.warning
        # Optioneel: stuur e-mail
        # echo "IP $ip: $count mislukte pogingen" | mail -s "SSH Alert" "$ADMIN_EMAIL"
    fi
done
# Maak het script uitvoerbaar en plan het via cron
sudo chmod +x /usr/local/bin/ssh-monitor.sh

# Voeg toe aan crontab (elk uur uitvoeren)
echo "0 * * * * root /usr/local/bin/ssh-monitor.sh" | sudo tee /etc/cron.d/ssh-monitor

SSH Hardening Valideren met ssh-audit

Na al dat configuratiewerk wil je natuurlijk weten of alles daadwerkelijk goed staat. ssh-audit is een uitstekend open-source hulpmiddel dat je SSH-serverconfiguratie analyseert en beoordeelt.

# Installeer ssh-audit
pip3 install ssh-audit

# Of via pakketbeheer
# Debian/Ubuntu:
sudo apt install ssh-audit

# Scan je eigen server
ssh-audit localhost -p 2222

# Voorbeeld uitvoer (verkort):
# (gen) banner: SSH-2.0-OpenSSH_10.0
# (kex) mlkem768x25519-sha256          -- [info] available since OpenSSH 9.9
# (kex) sntrup761x25519-sha512         -- [info] available since OpenSSH 8.5
# (kex) curve25519-sha256              -- [info] available since OpenSSH 7.4
# (key) ssh-ed25519                    -- [info] available since OpenSSH 6.5
# (enc) [email protected]         -- [info] available since OpenSSH 6.2
# (mac) [email protected]  -- [info] available since OpenSSH 6.2
#
# Overall Rating: A+

# Scan en sla het rapport op
ssh-audit localhost -p 2222 -j > ssh-audit-rapport.json

# Vergelijk met de aanbevolen configuratie van ssh-audit.com
ssh-audit --policy-file hardening-policy.txt localhost -p 2222

Een A+ rating van ssh-audit bevestigt dat je configuratie voldoet aan de strengste beveiligingsnormen. Voer deze scan regelmatig uit — bij voorkeur geautomatiseerd — om te controleren of de configuratie na updates nog steeds in orde is. Niets is vervelender dan ontdekken dat een pakketupdate stilletjes je instellingen heeft overschreven.

Post-Quantum Migratiestrategie

De migratie naar post-quantumcryptografie hoeft niet in één keer. Sterker nog, ik raad een gefaseerde aanpak aan:

Fase 1: Inventarisatie (Nu)

# Controleer de OpenSSH-versie op al je servers
ssh -V

# Inventariseer welke KexAlgorithms momenteel in gebruik zijn
sshd -T | grep kexalgorithms

# Controleer welke sleuteltypes in gebruik zijn
for host in $(cat /etc/hosts.allow | grep sshd); do
    echo "=== $host ==="
    ssh-keyscan -t ed25519,rsa $host 2>/dev/null | ssh-keygen -lf -
done

# Zoek naar verouderde DSA-sleutels in het hele netwerk
grep -r "ssh-dss" /home/*/.ssh/authorized_keys 2>/dev/null

Fase 2: Upgrade en Test (Binnen 3 Maanden)

  • Upgrade naar OpenSSH 10.0 of hoger op testomgevingen
  • Verifieer dat alle SSH-clients de nieuwe algoritmen ondersteunen
  • Test de hybride post-quantumalgoritmen in je specifieke omgeving
  • Verwijder alle DSA-sleutels en vervang ze door Ed25519

Fase 3: Uitrol in Productie (Binnen 6 Maanden)

  • Rol de nieuwe configuratie uit in productie, server voor server
  • Monitor actief voor compatibiliteitsproblemen met oudere clients
  • Documenteer de nieuwe standaarden in je beveiligingsbeleid

Fase 4: Handhaving (Binnen 12 Maanden)

  • Schakel alle niet-post-quantum key exchange-methoden uit
  • Blokkeer verbindingen van clients die de nieuwe algoritmen niet ondersteunen
  • Voer regelmatige audits uit met ssh-audit

Deze tijdlijn sluit aan bij de CNSA 2.0-standaarden van de Amerikaanse overheid, die in 2026 de verplichte transitie naar post-quantumalgoritmen markeren. Ook de EU beweegt in dezelfde richting als onderdeel van het bredere cybersecurity-beleid. Wachten is geen optie meer, eigenlijk.

Distributie-Specifieke Overwegingen

Niet alle Linux-distributies gaan op dezelfde manier met SSH-hardening om. Hier zijn de belangrijkste verschillen waar je rekening mee moet houden.

RHEL/AlmaLinux/Rocky Linux 10.x

De RHEL 10.1-distributies (uitgebracht eind 2025) hebben post-quantum algoritmen standaard ingeschakeld. In RHEL 10.0 waren deze nog als experimenteel gemarkeerd. Controleer wel of de zwakkere algoritmen daadwerkelijk zijn uitgeschakeld:

# Controleer het actieve crypto-beleid
update-crypto-policies --show

# Stel het strengste beleid in
sudo update-crypto-policies --set FUTURE

# Of gebruik een aangepast beleid voor SSH
sudo update-crypto-policies --set DEFAULT:NO-SHA1:NO-WEAKMAC

Debian/Ubuntu

Debian en Ubuntu hanteren een ander configuratiemodel. SSH-configuratie kan worden verdeeld over meerdere bestanden, wat zowel handig als verwarrend kan zijn:

# Debian/Ubuntu-specifieke configuratie
# Hoofdconfiguratie: /etc/ssh/sshd_config
# Aanvullende configuratie: /etc/ssh/sshd_config.d/*.conf

# Maak een hardening-configuratiebestand
sudo tee /etc/ssh/sshd_config.d/hardening.conf << 'EOF'
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256
Ciphers [email protected],[email protected],aes256-ctr
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
EOF

# Valideer de configuratie voordat je herstart
sudo sshd -t

# Herstart als de validatie slaagt
sudo systemctl restart sshd

Belangrijk: test altijd met sshd -t voordat je herstart. Een fout in de configuratie kan ertoe leiden dat sshd niet meer opstart, waardoor je de toegang tot je server verliest. Dat is het soort fout dat je maar één keer maakt. Houd bij remote servers altijd een bestaande SSH-sessie open terwijl je wijzigingen test.

Complete Configuratie Checklist

Gebruik deze checklist om te verifiëren dat je SSH-hardening volledig is geïmplementeerd:

  1. OpenSSH-versie: Draai je OpenSSH 10.0 of hoger?
  2. Protocol: Is alleen SSH-protocol 2 toegestaan?
  3. Root login: Is PermitRootLogin no ingesteld?
  4. Wachtwoorden: Is PasswordAuthentication no ingesteld?
  5. Gebruikers: Zijn alleen geautoriseerde gebruikers/groepen toegestaan via AllowUsers of AllowGroups?
  6. Key Exchange: Staat mlkem768x25519-sha256 bovenaan de KexAlgorithms-lijst?
  7. Ciphers: Worden alleen AES-256 en ChaCha20 ondersteund?
  8. Hostsleutels: Worden alleen Ed25519 en RSA-4096 gebruikt?
  9. DSA: Zijn alle DSA-sleutels verwijderd?
  10. Forwarding: Zijn X11, TCP en agent forwarding uitgeschakeld?
  11. Timeouts: Zijn ClientAliveInterval en LoginGraceTime ingesteld?
  12. Brute-force: Is Fail2Ban geconfigureerd en actief?
  13. Logging: Is LogLevel VERBOSE ingesteld?
  14. Audit: Zijn auditd-regels voor SSH geconfigureerd?
  15. MFA: Is multi-factor authenticatie ingeschakeld op bastion hosts?
  16. Validatie: Geeft ssh-audit een A+ rating?

Conclusie

SSH-hardening in 2026 gaat een stuk verder dan de traditionele maatregelen die we jarenlang hebben gebruikt. De komst van OpenSSH 10.0 met standaard post-quantumcryptografie, de architecturale scheiding via sshd-auth, en de volledige verwijdering van DSA markeren een nieuw tijdperk in SSH-beveiliging.

De actiepunten zijn duidelijk: upgrade naar OpenSSH 10.0, implementeer post-quantumalgoritmen, overweeg certificaatauthenticatie voor schaalbaarheid, voeg MFA toe op kritieke toegangspunten, en zorg voor robuuste monitoring en logging. Met 89% van alle Linux-aanvalsgedrag gericht op SSH brute-force zijn deze maatregelen niet optioneel — ze zijn noodzakelijk.

En vergeet niet: beveiliging is geen eindbestemming maar een continu proces. Plan regelmatige audits met ssh-audit, houd je software up-to-date, en pas je configuratie aan naarmate nieuwe dreigingen en algoritmen verschijnen. De post-quantumtransitie is begonnen — zorg dat jouw infrastructuur er klaar voor is.

Over de Auteur Editorial Team

Our team of expert writers and editors.