SSH-sleutels beheren: de praktische standaard voor 2026

Gebruik Ed25519 als standaardalgoritme, genereer één sleutelpaar per apparaat met een duidelijke naamconventie, en bewaar elke private key achter een passphrase of in hardware. Centraliseer daarnaast je inventaris, rotatieschema en intrekkingsproces, want handmatig SSH-sleutelbeheer loopt vroeg of laat vast op schaal en zichtbaarheid.

Kort samengevat:

• Alleen Ed25519 gebruiken als standaard voor nieuwe SSH-sleutels, met elke sleutel per apparaat en voldoende beveiliging zoals passphrases en hardware tokens.
• Publieke sleutels veilig op de server plaatsen via ssh-copy-id of strikte handmatige procedures om permissieproblemen en beveiligingsrisico’s te voorkomen.
• Bestandsrechten voor SSH-bestanden strikt handhaven en inrichten op ~/.ssh 700, privé sleutels en authorized_keys 600, en wachtwoordauthenticatie uitschakelen.
• SSH-sleutels tijdig roteren, vooral voor service-accounts, en direct intrekken bij medewerkerswisseling of in geval van verlies, met centrale inventarisatie en logging.
• Bij meerdere servers en teams overstappen op gecentraliseerde SSH-beheertools zoals certificaten, secrets-platforms of bastion-hosts voor betere controle en beveiliging.

Inhoudsopgave

• Wat is een SSH-key en waarom is het een credential, geen instelling
• Hoe genereer je een SSH-sleutel: Ed25519 of toch RSA?
• Hoe zet je je publieke sleutel veilig op een server
• Welke permissies en sshd-instellingen voorkomen toegangsproblemen
• Passphrases, ssh-agent en hardwaresleutels: waar ligt de balans
• Hoe vaak moet je SSH-sleutels roteren en intrekken
• Wanneer stap je over op centrale SSH-sleutelbeheer tools
• NLXS-perspectief: hoe wij SSH-sleutelbeheer praktisch aanpakken
• Grip op SSH-toegang zonder het zelf te hoeven bijhouden
• Bronnen
• Veelgestelde vragen

Wat is een SSH-key en waarom is het een credential, geen instelling

Een SSH-sleutelpaar bestaat uit een publieke en een private sleutel. De server bewaart de publieke sleutel in authorized_keys, terwijl de private sleutel op jouw apparaat blijft en nooit wordt verzonden. Bij het inloggen bewijst je apparaat via een challenge-response dat het de bijbehorende private sleutel bezit, zonder die sleutel ooit prijs te geven.

Dat mechanisme is elegant, maar het heeft één zwak punt: een sleutel verloopt niet vanzelf. Waar een wachtwoord soms na negentig dagen wordt afgedwongen, blijft een SSH-sleutel jarenlang geldig tenzij iemand hem actief intrekt. Dat leidt tot wildgroei: oud-medewerkers met nog werkende toegang, testservers met vergeten sleutels, en niemand die precies weet welke sleutel bij welke gebruiker en welke host hoort. Onderzoek naar SSH-sleutelbeheer laat zien dat een groot deel van de sleutels in authorized_keys-bestanden bij organisaties verouderd is, simpelweg omdat er geen inventaris bestaat. Behandel elke sleutel dus als credential met een eigenaar, een doel en een houdbaarheidsdatum.

Hoe genereer je een SSH-sleutel: Ed25519 of toch RSA?

Voor nieuwe sleutels is Ed25519 de aanbevolen keuze. Het algoritme is sneller, genereert kortere sleutels en is minder gevoelig voor implementatiefouten dan RSA, wat praktische lifecycle-gidsen ook als standaard voor 2026 aanhouden. Het commando is eenvoudig:

ssh-keygen -t ed25519 -C "[email protected]"

RSA blijft relevant in drie situaties: verouderde systemen die Ed25519 niet ondersteunen, omgevingen met een FIPS-vereiste, of compatibiliteit met oudere netwerkapparatuur. Kies dan een adequate sleutelgrootte zoals aanbevolen door relevante richtlijnen.

Twee regels voorkomen negentig procent van de latere problemen:

• Genereer één sleutelpaar per apparaat, nooit één sleutel die je kopieert naar laptop, thuis-pc en server tegelijk.
• Stel altijd een passphrase in op gebruikerssleutels, ook als dat een extra typstap kost bij elke sessie.

Hoe zet je je publieke sleutel veilig op een server

Het snelste en veiligste pad loopt via ssh-copy-id. Het commando kopieert je publieke sleutel naar de juiste server, voegt hem toe aan authorized_keys en zet meteen de correcte permissies, wat menselijke fouten voorkomt die bij handmatig kopiëren vaak misgaan.

Werkt ssh-copy-id niet, bijvoorbeeld op een minimale of afgesloten server, volg dan deze stappen:

1. Maak de map aan: mkdir -p ~/.ssh
2. Beperk de rechten: chmod 700 ~/.ssh
3. Voeg je publieke sleutel toe: cat id_ed25519.pub >> ~/.ssh/authorized_keys
4. Zet de bestandsrechten strak: chmod 600 ~/.ssh/authorized_keys
5. Test de verbinding met verbose-logging: ssh -vvv gebruiker@server

De verbose-modus toont exact welke sleutel wordt aangeboden en waar de authenticatie faalt. Meld de server “Permission denied (publickey)”, dan liggen de permissies of het pad naar authorized_keys bijna altijd aan de basis.

Welke permissies en sshd-instellingen voorkomen toegangsproblemen

Verkeerde bestandsrechten zijn de meest voorkomende reden dat SSH-authenticatie faalt, en tegelijk een veelvoorkomend beveiligingslek als ze te ruim staan. Houd deze indeling aan:

Aan de serverkant loont het om PasswordAuthentication no in te stellen in sshd_config, zodat wachtwoordaanvallen überhaupt geen kans krijgen. Beperk PermitRootLogin tot het strikt noodzakelijke, bij voorkeur uitgeschakeld, en dwing gebruikers via een eigen account met sudo-rechten naar binnen. Voor gedeelde of gevoelige servers kun je authorized_keys zelfs onder een root-owned pad plaatsen dat gebruikers niet zelf kunnen wijzigen, wat ongeautoriseerde zelf-toegevoegde sleutels onmogelijk maakt.

Passphrases, ssh-agent en hardwaresleutels: waar ligt de balans

Een passphrase alleen voelt onhandig als je tien keer per dag inlogt. Daarom bestaat ssh-agent: je ontgrendelt de private key eenmalig per sessie, en de agent onthoudt hem tijdelijk zonder de passphrase telkens opnieuw te vragen.

Agent-forwarding, waarbij je jouw lokale agent doorgeeft aan een server om vandaaruit weer verder te springen, is comfortabel maar riskant. Een gecompromitteerde tussenserver kan die doorgestuurde agent misbruiken om zich voor te doen als jou. Gebruik in plaats daarvan ProxyJump voor het springen tussen servers, zonder de agent bloot te stellen.

Voor beheerdersaccounts met kritieke toegang is een hardware-ondersteunde sleutel zoals ed25519-sk een verstandige stap. De private sleutel verlaat dan nooit een fysieke FIDO2-token, wat het risico van diefstal via malware vrijwel wegneemt. Beveiligingsexperts adviseren dit expliciet te combineren met multifactor-authenticatie voor accounts met verhoogd risico. Bewaar wel een herstelprocedure voor het geval het token verloren gaat.

Hoe vaak moet je SSH-sleutels roteren en intrekken

Voor gewone gebruikersaccounts is een rotatieperiode van 90 tot 180 dagen een werkbaar uitgangspunt, zoals NIST IR 7966 aanbeveelt via het concept van cryptoperiods. Voor CI/CD-pijplijnen en service-accounts geldt een kortere cyclus, omdat die sleutels vaak breder toegankelijk zijn en minder menselijk toezicht kennen.

Bij vertrek van een medewerker of een vermoeden van verlies geldt één regel: onmiddellijke intrekking, niet “bij de volgende rotatieronde”. Handmatig een sleutel uit tientallen authorized_keys-bestanden verwijderen kost uren; met centrale tooling is dat een kwestie van minuten.

Praktische maatregelen die dit ondersteunen:

• Houd een fingerprint-overzicht bij van elke sleutel die toegang heeft tot productiesystemen.
• Koppel SSH-logs aan je SIEM-oplossing, zodat je forensisch kunt herleiden wie wanneer met welke sleutel inlogde.
• Documenteer per sleutel de eigenaar, het doel en de vervaldatum, niet alleen de fingerprint.

Praktijkervaring bij JumpServer bevestigt dat organisaties zonder realtime inventaris structureel te laat zijn met intrekken, simpelweg omdat niemand meer weet welke sleutel nog actief is.

Wanneer stap je over op centrale SSH-sleutelbeheer tools

Bij een handvol servers en een klein team werkt handmatig beheer nog. Zodra je meerdere omgevingen, wisselende contractors of een groeiend team hebt, wordt handmatig bijhouden van authorized_keys-bestanden een operationeel risico in plaats van een taak.

Drie categorieën tooling lossen dit gestructureerd op:

• Geheimenmanagers zoals gecentraliseerde secrets-platformen bewaren private keys versleuteld, regelen rotatie automatisch en geven één plek waar je precies ziet welke sleutel waar wordt gebruikt. Praktijkvoorbeelden van dergelijke platformen laten zien hoe dit hardcoded sleutels in scripts en configuratiebestanden overbodig maakt.
• SSH-certificaten via een eigen SSH CA vervangen losse publieke sleutels door tijdsgebonden certificaten. Een certificaat verloopt automatisch na een ingestelde periode, wat intrekken sterk vereenvoudigt: je hoeft niet elke server langs, want het certificaat werkt simpelweg niet meer.
• Bastion-hosts met just-in-time toegang geven gebruikers pas tijdelijk toegang op het moment dat ze die nodig hebben, vaak gecombineerd met sessie-opname voor audits.

Voor de meeste mkb-organisaties is de overstap naar SSH-certificaten de grootste efficiëntiewinst per geïnvesteerd uur, omdat het intrekkingsprobleem in één klap wordt opgelost. Grotere teams met strikte compliance-eisen combineren dit vaak met een bastion-oplossing voor volledige traceerbaarheid. Een heldere afbakening van toegangsrechten hoort in beide gevallen bij het ontwerp, niet als nazorg.

NLXS-perspectief: hoe wij SSH-sleutelbeheer praktisch aanpakken

Wij zien bij klanten steeds hetzelfde patroon: de techniek is zelden het probleem, het overzicht wel. Een bedrijf heeft misschien vijftien servers en acht mensen met toegang, maar niemand kan binnen vijf minuten zeggen welke sleutel bij wie hoort. Daarom combineren we bij NLXS inventarisatie, beleid en automatisering in één traject, in plaats van losse adviezen te geven die niemand uitvoert.

Sommige organisaties kiezen daarbij voor snelheid: problemen worden doorgaans binnen één dag opgelost, ook bij toegangsincidenten. Twijfel je of jouw sleutelbeheer nog klopt? Een korte SSH-audit legt binnen een paar dagen bloot waar de risico’s zitten.

— Ken

Grip op SSH-toegang zonder het zelf te hoeven bijhouden

Er zijn alternatieven voor de spreadsheet-met-fingerprints-aanpak die veel mkb-bedrijven noodgedwongen hanteren: sleutelbeheer, rotatie en intrekking kunnen ingebouwd worden als vast onderdeel van beheer, vaak tegen een vast maandbedrag zonder verrassingen.

Met hosted serverbeheer leggen we centrale monitoring en toegangbeheer bij je infrastructuur neer, zodat een vertrekkende medewerker of een verdachte inlogpoging niet wekenlang onopgemerkt blijft. Daarnaast helpt onze ICT-consultancy om beleid rond least privilege en sleutelrotatie op papier én in de praktijk te krijgen, en zorgt netwerkbeheer ervoor dat toegang tot je netwerk net zo strak is afgesloten als de servers zelf. Wil je weten hoe jouw huidige SSH-toegang ervoor staat? Vraag een ICT-scan aan via Nlxs en we brengen binnen korte tijd in kaart waar de risico’s zitten en wat een oplossing kost.

Bronnen

Voor de technische onderbouwing van cryptoperiods en logging is NIST IR 7966 de referentie die de meeste enterprise-beleidsdocumenten aanhouden. Voor de architectuurkant, met name rond just-in-time toegang en centrale inventaris, biedt JumpServer bruikbare praktijkinzichten. Wie direct aan de slag wil met commando’s en een volledige lifecycle-aanpak vindt in de SSH-sleutelgids van Bytepane een praktische uitwerking van generatie tot intrekking.

• NIST.IR.7966
• SSH key management best practices – JumpServer
• SSH Key Lifecycle 2026: Generate, Add, Rotate & Audit Keys
• Basisprimer voor het vastzetten van SSH

Veelgestelde vragen

Wat is een SSH-sleutel precies?

Een SSH-sleutel is een cryptografisch sleutelpaar dat bestaat uit een publieke en een private sleutel, gebruikt om veilig in te loggen op een server zonder wachtwoord. De publieke sleutel staat op de server, de private sleutel blijft op jouw apparaat en verlaat dat nooit.

Hoe maak je een SSH-sleutel aan?

Gebruik het commando ssh-keygen -t ed25519 -C "[email protected]" om een modern en veilig sleutelpaar te genereren. Stel altijd een passphrase in tijdens het aanmaakproces, zodat een gestolen private key alleen niet direct bruikbaar is.

Hoe log je in met SSH via een sleutel?

Nadat je publieke sleutel op de server staat via ssh-copy-id of handmatig in authorized_keys, log je in met ssh gebruiker@server. SSH herkent automatisch de bijbehorende private sleutel op je apparaat en rondt de authenticatie stil af.

Hoe verbind je met SSH als het inloggen niet lukt?

Start de verbinding met ssh -vvv gebruiker@server om te zien op welk punt de authenticatie faalt. In de meeste gevallen liggen verkeerde permissies op ~/.ssh of authorized_keys aan de basis, of ontbreekt de juiste sleutel in de agent.

Wanneer moet ik overstappen naar centraal SSH-sleutelbeheer?

Zodra je meerdere servers, wisselende teamleden of externe contractors beheert, wordt handmatig bijhouden van sleutels foutgevoelig. Diensten zoals hosted serverbeheer van NLXS nemen inventarisatie, rotatie en intrekking dan gecentraliseerd over.

Aanbevelingen

• Begin op dag 1: serverhardening voor beheerders, 3 acties
• Remote beheer servers: veilige checklist voor IT-teams
• Endpoint beveiliging voor IT-teams: complete gids 2026