SSH beveiligen op een Linux VPS: complete sshd_config gids

12 min leestijd·Matthieu|

Vergrendel SSH op je Debian 12 of Ubuntu 24.04 VPS. Ed25519-sleutelgeneratie, sshd_config hardening, ProxyJump bastion-configuratie, cipher hardening en verificatie met ssh-audit. Elke wijziging getest voordat je verdergaat.

SSH is de voordeur van je server. Geautomatiseerde bots beginnen poort 22 te bestoken binnen enkele minuten nadat een VPS online komt. Deze gids behandelt elke sshd_config-wijziging die nodig is om SSH te vergrendelen op Debian 12 (OpenSSH 9.2) en Ubuntu 24.04 (OpenSSH 9.6), met een verificatiestap na elke wijziging zodat je weet dat het daadwerkelijk werkt.

Vereisten

Je hebt nodig:

  • Een VPS met Debian 12 of Ubuntu 24.04 (nieuw of bestaand)
  • Een niet-root gebruiker met sudo-toegang
  • Een tweede terminal of SSH-sessie naar de server (je hebt deze nodig om wijzigingen te testen zonder jezelf buitensluiten)

Deze gids maakt deel uit van de Linux VPS Security: Threats, Layers, and Hardening Guide serie. Na het beveiligen van SSH hier, stel je geautomatiseerde brute-force bescherming in met .

Hoe genereer ik een veilige SSH-sleutel voor mijn VPS?

Genereer een Ed25519-sleutel op je lokale machine (je laptop of werkstation, niet de server). Ed25519 produceert een 256-bit sleutel die 128 bits beveiliging biedt, gelijkwaardig aan RSA-3072, maar sneller te genereren en te verifiëren. De handtekeningen zijn deterministisch, dus ze zijn niet afhankelijk van een random number generator op het moment van ondertekening. Dit elimineert een hele klasse van implementatie-aanvallen die RSA treffen.

ssh-keygen -t ed25519 -C "yourname@yourmachine"

Je ziet output zoals dit:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourname/.ssh/id_ed25519
Your public key has been saved in /home/yourname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xR5xGk3TOs4mEfW8sBv7g7LkE2PLxYae2TqfGxpfM3Q yourname@yourmachine

Stel een wachtwoordzin in. Als iemand je private key-bestand steelt, is de wachtwoordzin het enige dat tussen hen en je servers staat.

Ed25519 vs RSA: welke sleutel moet ik gebruiken?

Ed25519 RSA-4096
Sleutelgrootte 256 bits 4096 bits
Beveiligingssterkte ~128 bits ~140 bits
Sleutelgeneratie Direct 1-5 seconden
Handtekeningverificatie Sneller Langzamer
Private key bestandsgrootte 464 bytes ~3,3 KB
RNG-afhankelijkheid bij ondertekening Nee (deterministisch) Ja
Compatibiliteit OpenSSH 6.5+ (2014) Universeel

Gebruik Ed25519 tenzij je moet verbinden met systemen die OpenSSH ouder dan 6.5 draaien, wat zeldzaam is in 2026.

Kopieer je publieke sleutel naar de server

Vanaf je lokale machine:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Als ssh-copy-id niet beschikbaar is (sommige macOS-installaties), kopieer handmatig:

cat ~/.ssh/id_ed25519.pub | ssh youruser@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Verifieer: Log in vanuit een nieuwe terminal met sleutelauthenticatie:

ssh -i ~/.ssh/id_ed25519 youruser@your-server-ip

Als je een shell krijgt zonder je serverwachtwoord in te voeren (alleen je sleutel-wachtwoordzin), werkt sleutelauthenticatie.

De Include-directive begrijpen

Voordat je sshd_config bewerkt, moet je dit weten: zowel Debian 12 als Ubuntu 24.04 worden geleverd met Include /etc/ssh/sshd_config.d/*.conf bovenaan /etc/ssh/sshd_config. OpenSSH gebruikt de eerste waarde die het vindt voor de meeste directives. Elk .conf-bestand in sshd_config.d/ krijgt voorrang op instellingen in het hoofdbestand.

Controleer wat er al is ingesteld:

ls -la /etc/ssh/sshd_config.d/

Op Ubuntu 24.04 vind je meestal 50-cloud-init.conf als cloud-init actief is. Lees bestaande bestanden voordat je wijzigingen aanbrengt:

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null

We plaatsen onze hardening in een enkel bestand dat als eerste wordt geladen:

sudo touch /etc/ssh/sshd_config.d/00-hardening.conf
sudo chmod 600 /etc/ssh/sshd_config.d/00-hardening.conf

Het 00- prefix zorgt ervoor dat ons bestand wordt gelezen voor andere config-fragmenten. De chmod 600 beperkt leestoegang tot alleen root, aangezien dit bestand bepaalt wie kan inloggen.

Alle sshd_config-wijzigingen in deze gids gaan in /etc/ssh/sshd_config.d/00-hardening.conf tenzij anders vermeld.

Hoe schakel ik SSH-wachtwoordauthenticatie uit?

Het uitschakelen van wachtwoordauthenticatie dwingt inloggen met alleen sleutels af. Brute-force aanvallen worden zinloos omdat er geen wachtwoord is om te raden.

Open het hardening-configuratiebestand:

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

Voeg toe:

PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication vervangt het verouderde ChallengeResponseAuthentication in OpenSSH 9.x. Schakel beide uit om alle wachtwoordgebaseerde inlogpaden te sluiten.

Valideer altijd de configuratie en houd je huidige sessie open voordat je sshd herstart.

sudo sshd -t

Als er geen output is, is de configuratie geldig. Fouten worden naar de terminal geprint.

Herstart nu sshd:

sudo systemctl restart sshd

Verifieer vanuit een tweede terminal (sluit je huidige sessie niet):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@your-server-ip

Je zou moeten zien:

youruser@your-server-ip: Permission denied (publickey).

Dat bevestigt dat wachtwoordauthenticatie uit staat. Let op: er staat (publickey) als enige toegestane methode. Dit is precies wat we willen.

Bevestig nu dat sleutelinloggen nog steeds werkt vanuit diezelfde tweede terminal:

ssh youruser@your-server-ip

Als beide tests slagen, is wachtwoordauthenticatie uitgeschakeld en werkt sleutelinloggen. Als sleutelinloggen mislukt, ga terug naar je nog openstaande eerste sessie en corrigeer de configuratie voordat je buitengesloten raakt.

Hoe schakel ik SSH root-login uit op Ubuntu en Debian?

Directe root-login via SSH moet uit staan. Zelfs met alleen sleutelauthenticatie geeft een gecompromitteerde root-sleutel volledige systeemtoegang zonder audit trail van wie er is ingelogd. Gebruik in plaats daarvan een gewone gebruiker met sudo.

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

PermitRootLogin no

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer vanuit een tweede terminal:

ssh root@your-server-ip

Verwachte output:

root@your-server-ip: Permission denied (publickey).

Controleer of de instelling is doorgevoerd met sshd -T (hoofdletter T toont de actieve configuratie):

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Hoe beperk ik SSH-toegang tot specifieke gebruikers en groepen?

AllowUsers en AllowGroups beperken SSH-login tot een expliciete lijst. Iedereen die niet op de lijst staat wordt geweigerd, zelfs als ze geldige sleutels hebben. Dit is een vangnet tegen onbedoelde sleuteluitrol of nieuwe gebruikers die door packages worden aangemaakt.

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

AllowUsers youruser

Vervang youruser door je werkelijke gebruikersnaam. Voor meerdere gebruikers:

AllowUsers youruser deployer

Als alternatief, gebruik groepsgebaseerde toegang (beter voor teams):

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

Dan in de configuratie:

AllowGroups sshusers

Verwerkingsvolgorde

OpenSSH evalueert toegang in deze volgorde: DenyUsers, AllowUsers, DenyGroups, AllowGroups. Een deny in welke fase dan ook blokkeert de gebruiker. Als je AllowUsers gebruikt, kunnen alleen vermelde gebruikers inloggen. Als je AllowGroups gebruikt, kunnen alleen leden van vermelde groepen inloggen. Je kunt ze combineren, maar AllowUsers wordt eerst gecontroleerd.

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer vanuit een tweede terminal:

ssh youruser@your-server-ip

Bevestig dat je gebruiker nog steeds kan inloggen. Controleer vervolgens dat een niet-vermelde gebruiker zou worden geweigerd:

sudo sshd -T | grep -i allowusers

allowusers youruser

Welke SSH-sessielimieten moet ik instellen?

Deze directives beperken authenticatiepogingen, verbindingstime-outs en niet-geauthenticeerde verbindingen. Ze vertragen brute-force aanvallen en ruimen verlopen sessies op.

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

Dit is wat elke instelling doet:

Directive Waarde Effect
MaxAuthTries 3 Verbreekt verbinding na 3 mislukte authenticatiepogingen per verbinding
LoginGraceTime 20 Geeft 20 seconden om te authenticeren voor het verbreken
MaxStartups 10:30:60 Na 10 niet-geauthenticeerde verbindingen wordt 30% van nieuwe willekeurig gedropt. Bij 60 worden alle nieuwe verbindingen gedropt.
MaxSessions 3 Maximaal 3 gemultiplexte sessies per verbinding
ClientAliveInterval 300 Stuurt elke 300 seconden (5 minuten) een keepalive-pakket
ClientAliveCountMax 2 Verbreekt verbinding na 2 gemiste keepalive-antwoorden

ClientAliveInterval berekening: De werkelijke idle time-out is ClientAliveInterval x ClientAliveCountMax. Met deze waarden: 300 x 2 = 600 seconden = 10 minuten. Een inactieve sessie wordt na 10 minuten zonder respons verbroken.

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer:

sudo sshd -T | grep -E "maxauthtries|logingracetime|maxstartups|maxsessions|clientaliveinterval|clientalivecountmax"

maxauthtries 3
logingracetime 20
maxstartups 10:30:60
maxsessions 3
clientaliveinterval 300
clientalivecountmax 2

Schakel onnodige forwarding-functies uit

Forwarding-functies vergroten het aanvalsoppervlak van SSH. Schakel alles uit wat je niet actief gebruikt.

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer:

sudo sshd -T | grep -E "allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel"

allowagentforwarding no
allowtcpforwarding no
x11forwarding no
permittunnel no

Waarom moet ik SSH agent forwarding uitschakelen?

Agent forwarding laat een remote server je lokale SSH-sleutels gebruiken om te authenticeren bij andere servers. Dit klinkt handig om tussen machines te springen. Het probleem: iemand met root op die remote server kan je agent-socket kapen en je sleutels gebruiken.

Het aanvalsscenario:

  1. Je schakelt agent forwarding in en maakt een SSH-verbinding naar Server A.
  2. OpenSSH maakt een socket aan op /tmp/ssh-XXXX/agent.YYYY op Server A.
  3. Een aanvaller met root op Server A leest de SSH_AUTH_SOCK omgevingsvariabele uit je sessie.
  4. De aanvaller verbindt met die socket: SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
  5. Server B ziet een geldige authenticatie met jouw sleutel. De aanvaller is binnen.

De aanvaller heeft nooit je private key aangeraakt. Ze hadden alleen root nodig op de tussenliggende server terwijl je sessie actief was.

Gebruik in plaats daarvan ProxyJump (volgende sectie). Het biedt dezelfde multi-hop toegang zonder je agent-socket bloot te stellen aan een tussenliggende server.

Hoe configureer ik SSH ProxyJump voor bastion host-toegang?

ProxyJump routeert je SSH-verbinding via een jump host (bastion) zonder agent forwarding. Je sleutels verlaten nooit je lokale machine. De verbinding is end-to-end versleuteld: de bastion ziet alleen versleuteld verkeer dat passeert.

Gebruik via de opdrachtregel

ssh -J jumpuser@bastion.example.com targetuser@10.0.1.50

De -J flag vertelt SSH om eerst verbinding te maken met de bastion en vervolgens door te tunnelen naar het doel. Je kunt meerdere hops aan elkaar koppelen met komma's:

ssh -J jump1@bastion1,jump2@bastion2 targetuser@10.0.1.50

SSH config-bestand instellen

Voor regelmatig gebruik, voeg entries toe aan ~/.ssh/config op je lokale machine:

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal-app
    HostName 10.0.1.50
    User appuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host internal-db
    HostName 10.0.2.100
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Verbind nu direct met interne servers:

ssh internal-app

SSH handelt de bastion-hop automatisch af.

De bastion-server beveiligen

Beperk op de bastion host wat jump-gebruikers kunnen doen. Voeg toe aan de sshd_config van de bastion:

Match User jumpuser
    PermitTTY no
    X11Forwarding no
    PermitTunnel no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes

Dit staat TCP forwarding toe (nodig voor ProxyJump) maar voorkomt dat de jump-gebruiker een shell krijgt, commando's uitvoert of X11 gebruikt. Als de bastion gecompromitteerd wordt, krijgt de aanvaller een forwarding-only account zonder shell-toegang.

Welke SSH-ciphers en key exchange-algoritmen zijn veilig?

Standaard cipher-lijsten in OpenSSH bevatten algoritmen die behouden zijn voor achterwaartse compatibiliteit. Het verwijderen van zwakke algoritmen verkleint je aanvalsoppervlak. Deze aanbevelingen zijn gericht op OpenSSH 9.2+ (Debian 12) en 9.6+ (Ubuntu 24.04).

Genereer eerst opnieuw host keys met alleen Ed25519 en verwijder eventuele DSA- of ECDSA-sleutels:

sudo rm -f /etc/ssh/ssh_host_*key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

We bewaren een RSA host key voor clients die Ed25519 niet ondersteunen (zeldzaam, maar het voorkomt lockouts).

Verwijder vervolgens zwakke Diffie-Hellman moduli (groepen kleiner dan 3072 bits):

sudo awk '$5 >= 3071' /etc/ssh/moduli > /tmp/moduli.safe
sudo mv /tmp/moduli.safe /etc/ssh/moduli
sudo chown root:root /etc/ssh/moduli
sudo chmod 644 /etc/ssh/moduli

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
Categorie Algoritmen Opmerkingen
Key exchange sntrup761x25519, curve25519, DH group16/18 sntrup761 is post-quantum hybride. curve25519 is de huidige standaard.
Ciphers ChaCha20-Poly1305, AES-256-GCM, AES-128-GCM, AES-CTR ChaCha20 eerst: sneller in software zonder AES-NI. GCM is authenticated encryption (geverifieerde versleuteling).
MACs HMAC-SHA2 ETM, UMAC-128 ETM Alleen ETM (Encrypt-then-MAC). Non-ETM modi zijn zwakker.
Host keys Ed25519, RSA (SHA-2) Geen DSA (gebroken). Geen ECDSA (vertrouwensproblemen met NIST-curves).

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer vanuit een tweede terminal dat je nog steeds kunt verbinden. Als je SSH-client geen van deze algoritmen ondersteunt (zeer oude client), krijg je een "no matching cipher" foutmelding. Update in dat geval je client of voeg tijdelijk het benodigde algoritme weer toe.

Configureer een login-banner

Verberg je SSH-versie-informatie en toon een juridische waarschuwingsbanner:

sudo nano /etc/ssh/banner.txt

Authorized access only. All activity is monitored and logged.

Houd het kort. Lange banners met systeeminformatie helpen aanvallers bij het vingerafdrukken van je OS.

Voeg toe aan /etc/ssh/sshd_config.d/00-hardening.conf:

Banner /etc/ssh/banner.txt
DebianBanner no

DebianBanner no verwijdert de Debian/Ubuntu versiestring uit de SSH-protocolbanner. Versie-onthulling helpt aanvallers bekende kwetsbaarheden te targeten voor jouw specifieke OpenSSH-build.

Valideer en herstart:

sudo sshd -t && sudo systemctl restart sshd

Verifieer vanaf je lokale machine:

ssh -v youruser@your-server-ip 2>&1 | grep "banner"

Volledige geharde sshd_config-referentie

Hier is het volledige /etc/ssh/sshd_config.d/00-hardening.conf met alle instellingen uit deze gids:

# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Access control
AllowUsers youruser

# Session limits
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Forwarding restrictions
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Cryptography
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

# Banner
Banner /etc/ssh/banner.txt
DebianBanner no

# Logging
LogLevel VERBOSE

LogLevel VERBOSE registreert extra details, waaronder key fingerprints die gebruikt zijn voor authenticatie. Handig om te auditen wie met welke sleutel heeft ingelogd.

Na het schrijven van dit bestand, valideer altijd voordat je herstart:

sudo sshd -t && sudo systemctl restart sshd

Controleer de volledige actieve configuratie:

sudo sshd -T

Dit toont elke actieve instelling, inclusief standaardwaarden. Pipe door grep om specifieke waarden te controleren:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

permitrootlogin no
passwordauthentication no
allowusers youruser

Hoe verifieer ik mijn SSH-hardening met ssh-audit?

ssh-audit scant je server en beoordeelt elk algoritme als good, warning of fail. Voer het uit na hardening om te bevestigen dat alles slaagt.

Installeer op je lokale machine of een aparte server (niet het doel):

pip3 install ssh-audit

Of met apt op Debian/Ubuntu:

sudo apt update && sudo apt install -y ssh-audit

Scan je server:

ssh-audit your-server-ip

Met de hardening uit deze gids zou je geen [fail] entries moeten zien. De output begint met de gedetecteerde OpenSSH-versie en toont vervolgens elke algoritmecategorie:

# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4
...

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
...

Als je [fail] entries ziet, controleer of je 00-hardening.conf is geladen (let op de Include-volgorde) en dat geen ander bestand in sshd_config.d/ je instellingen overschrijft.

ssh-audit heeft ook ingebouwde hardening-gidsen:

ssh-audit --list-hardening-guides

Probleemoplossing

Ik heb mezelf buitengesloten

Als je na een configuratiewijziging niet meer via SSH kunt inloggen:

  1. Gebruik de webconsole (KVM/VNC) van je VPS-provider om direct in te loggen.
  2. Corrigeer /etc/ssh/sshd_config.d/00-hardening.conf.
  3. Voer sshd -t uit om te valideren.
  4. Herstart: systemctl restart sshd.

Dit is waarom we zeggen: sluit nooit je werkende sessie voordat je test vanuit een tweede terminal.

sshd start niet na configuratiewijziging

sudo sshd -t

Dit print de exacte regel en het bestand met de fout. Veelvoorkomende problemen:

  • Typfout in een algoritmenaam (geen spaties toegestaan in de kommagescheiden lijsten)
  • Dubbele directives in meerdere bestanden (controleer sshd_config.d/ en het hoofd sshd_config)
  • AllowUsers met een gebruikersnaam die niet bestaat (sshd start, maar niemand kan inloggen)

Verbinding geweigerd na cipher hardening

Je lokale SSH-client ondersteunt mogelijk de geconfigureerde ciphers niet. Controleer welke ciphers je client ondersteunt:

ssh -Q cipher

Vergelijk met de serverlijst. Voeg de cipher die je client nodig heeft weer toe, of update je client.

SSH-logs controleren

sudo journalctl -u sshd -f

Bekijk de logs in realtime terwijl je een verbinding probeert vanuit een andere terminal. Authenticatiefouten, configuratiefouten en verbindingsonderbrekingen verschijnen hier allemaal.

Controleer welk configuratiebestand een directive instelt

sudo sshd -T | grep passwordauthentication

Als de waarde niet overeenkomt met wat je hebt ingesteld, overschrijft een ander bestand in sshd_config.d/ het jouwe. Bestanden worden in alfabetische volgorde geladen. Ons 00-hardening.conf wordt als eerste geladen en wint daardoor voor de meeste directives. Maar controleer op cloud-init of andere beheertools die hun eigen configuraties schrijven.

Verificatiechecklist

Loop dit door na het voltooien van alle hardening-stappen:

  1. Wachtwoordauth uitgeschakeld: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server geeft "Permission denied"
  2. Root-login uitgeschakeld: ssh root@server geeft "Permission denied"
  3. Sleutelauth werkt: ssh youruser@server geeft je een shell
  4. AllowUsers actief: sudo sshd -T | grep allowusers toont je gebruiker
  5. Sessielimieten ingesteld: sudo sshd -T | grep maxauthtries toont 3
  6. Forwarding uitgeschakeld: sudo sshd -T | grep allowagentforwarding toont no
  7. Alleen sterke ciphers: ssh-audit server-ip toont geen [fail] entries
  8. Logs werken: sudo journalctl -u sshd -n 20 toont recente auth-entries

Na het beveiligen van SSH, stel in om automatisch IP-adressen te blokkeren die authenticatie niet doorstaan. Voor SSH-toegangscontrole op netwerkniveau, zie .

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.

Klaar om het zelf te proberen?

Deploy uw eigen server in seconden. Linux, Windows of FreeBSD.

Bekijk VPS-aanbod