Waarom statische SSH-sleutels een risico vormen en hoe tijdelijke SSH-sleutels dit probleem oplossen.

SSH-sleutelbeheer is uitgegroeid tot een van de meest cruciale en tegelijkertijd minst gecontroleerde aspecten van bedrijfsbeveiliging. Statische SSH-sleutelparen vormen al decennia de basis voor veilige toegang op afstand en zijn nog steeds diep verankerd in de infrastructuur van de meeste organisaties. De eigenschappen die ze handig maken op kleine schaal, met name hun persistentie en het ontbreken van een vervalmechanisme, creëren beveiligingsrisico's die toenemen naarmate omgevingen groter worden.

In tegenstelling tot wachtwoorden die volgens een vast schema verlopen, of TLS-certificaten die browsers na hun vervaldatum weigeren, is een statisch wachtwoord SSH-sleutel Heeft geen ingebouwde vervaldatum. Zodra een publieke sleutel in een authorized_keys-bestand op een server is geplaatst, verleent deze onbeperkt toegang totdat iemand deze expliciet verwijdert. In omgevingen met honderden engineers, duizenden servers en geautomatiseerde systemen die sleutels genereren op elke laag van de infrastructuurstack, wordt die expliciete verwijderingsstap systematisch overgeslagen.

Een analyse van meer dan 14 miljoen SSH-clientsleutels in bedrijfsomgevingen toonde aan dat een gemiddelde grote organisatie meer dan 7,000 'root-toegangssleutels' heeft, minstens één per geanalyseerde server. Dit zijn sleutels met het hoogste toegangsniveau tot het systeem, die toebehoren aan identiteiten die niet langer binnen de organisatie bestaan ​​en die ongebruikt in de productie-infrastructuur aanwezig zijn. Dezelfde analyse wees uit dat veel organisaties een verhouding van tien SSH-sleutels per werknemer hebben, wat aangeeft hoe vaak sleutels worden aangemaakt en hoe zelden ze worden opgeruimd.

Tijdelijke sleutels pakken dit probleem aan op architecturaal niveau. In plaats van een permanent sleutelpaar te creëren dat blijft bestaan ​​totdat het handmatig wordt ingetrokken, worden tijdelijke sleutels op aanvraag gegenereerd voor een specifieke sessie of operationele periode en automatisch ongeldig gemaakt wanneer die sessie eindigt. Er is geen permanente toegang, geen achtergebleven inloggegevens en geen intrekkingsstap die iemand over het hoofd zou kunnen zien. Deze blog onderzoekt de specifieke faalmogelijkheden van statische SSH-sleutels, legt het technische mechanisme van de uitgifte van tijdelijke sleutels uit en beschrijft hoe organisaties de overgang kunnen starten zonder de bestaande infrastructuur te verstoren.

Hoe SSH-authenticatie met openbare sleutels werkt en waar het misgaat.

SSH-authenticatie met publieke sleutels is gedefinieerd in RFC 4252, sectie 7. Het is een op handtekeningen gebaseerd mechanisme in plaats van een door de server uitgegeven uitdaging-antwoordmechanisme. De client verzendt een SSH_MSG_USERAUTH_REQUEST met daarin de gebruikersnaam, de servicenaam, de methodenaam ("publickey"), het algoritme voor de publieke sleutel en de publieke sleutel zelf. De client kan er optioneel voor kiezen om het verzoek eerst te verzenden met de handtekeningvlag ingesteld op false; als de server bereid is die sleutel te accepteren, reageert deze met SSH_MSG_USERAUTH_PK_OK en kan de client het ondertekende verzoek verder verwerken.

Wanneer het verzoek wordt verzonden met de handtekeningvlag ingesteld op 'true', ondertekent de client een gedefinieerd gegevensblok, bestaande uit de sessie-ID geconcateneerd met de verzoekvelden, met behulp van de bijbehorende privésleutel. De server verifieert de handtekening aan de hand van de publieke sleutel die in het bestand authorized_keys voor de doelgebruiker staat vermeld. Als de verificatie slaagt, heeft de client bewezen in het bezit te zijn van de privésleutel zonder deze te verzenden.

De privésleutel zelf wordt niet via het netwerk verzonden; afhankelijk van de clientconfiguratie kan deze zich bevinden in een SSH-agent in het geheugen van de client, in een versleuteld sleutelbestand op de schijf, of op een hardwaretoken zoals een FIDO2-apparaat of smartcard, waar deze nooit het netwerk verlaat. Dit is een goed ontworpen cryptografisch protocol. Het beveiligingsprobleem zit niet in de handshake zelf, maar in wat er met de sleutels gebeurt nadat ze zijn aangemaakt en hoe lang ze in de authorized_keys-bestanden blijven staan.

SSH-sleutels verlopen niet.

Een statische SSH-sleutel heeft geen geldigheidsperiode. Zodra deze is toegevoegd aan authorized_keys, autoriseert deze onbeperkt toegang. Er bestaat geen equivalent voor een digitale certificaten niet-Na veld, en geen certificaat autoriteit dat herinneringen voor verlenging verstuurt. Brancheonderzoek wijst uit dat in de meeste grote organisaties het merendeel van de geautoriseerde sleutels inactief is, maar nog steeds toegang verleent.

Sleutelverwijdering is afhankelijk van handmatige processen die steevast mislukken.

Uit een onderzoek onder meer dan 550 CIO's van beveiligingsorganisaties bleek dat 96% beveiligingsbeleid hanteert dat vereist dat SSH-sleutels worden verwijderd wanneer een medewerker wordt ontslagen of van functie verandert. Echter, 40% van diezelfde organisaties erkent dat ze geen geautomatiseerde tools hebben om die verwijdering af te dwingen. De kloof tussen beleid en uitvoering wordt in theorie overbrugd door handmatige offboarding-stappen, waarbij een medewerker eraan moet denken om een ​​specifieke sleutel te verwijderen van elke server waartoe die sleutel toegang heeft. In omgevingen met honderden servers en een grote hoeveelheid sleutels verspreid over meerdere teams, mislukt dit proces regelmatig.

Een gecompromitteerde sleutel blijft geldig totdat deze wordt ontdekt.

Als een aanvaller een statische SSH-privésleutel verkrijgt via phishing, een openbaar gemaakt geheim van een CI/CD-pipeline of een per ongeluk gecommit code-repository, blijft die inloggegevens volledig geldig totdat iemand de inbreuk ontdekt en alle bijbehorende publieke sleutels verwijdert uit alle authorized_keys-bestanden in het gehele netwerk.

Uit het CrowdStrike Global Threat Report 2025 bleek dat 79% van de cyberaanvallen in 2024 malwarevrij was en gebruikmaakte van geldige inloggegevens. Een gestolen SSH-sleutel valt precies in deze categorie: legitiem, vertrouwd door de doelsystemen en onzichtbaar voor op signaturen gebaseerde detectietools.

SSH-sleutels genereren geen auditspoor op identiteitsniveau.

Standaard SSH-sleutelauthenticatie registreert alleen het bron-IP-adres en de sleutelvingerafdruk. Het registreert niet wie de sleutel heeft gebruikt, of het gebruik conform het beleid was, of welke commando's tijdens de sessie zijn uitgevoerd. Volgens PCI-DSS-vereiste 8, NIST 800-53 AU-controles en ISO 27001 Annex A.9 is dit gebrek aan traceerbaarheid op identiteitsniveau een governance-lacune die steeds moeilijker te dichten is naarmate de sleutelinventaris groeit.

Waarom de wildgroei aan SSH-sleutels in de loop der tijd toeneemt

De wildgroei aan SSH-sleutels is een probleem dat zich op geen enkele schaal stabiliseert. Elke nieuwe serverimplementatie creëert nieuwe authorized_keys-bestanden. Elke ontwikkelaar die bij de organisatie komt werken, genereert een sleutelpaar. Elke CI/CD-pipeline die naar de infrastructuur implementeert, creëert een servicesleutel. Elke externe partij voegt sleutels toe aan de systemen waartoe ze toegang hebben. Na verloop van tijd wordt in een typische grote onderneming de relatie tussen een sleutel en de identiteit of het systeem waartoe deze behoort steeds ondoorzichtiger.

Onderzoek in bedrijfsomgevingen heeft aangetoond dat 60 tot 90 procent van de organisaties geen volledig overzicht heeft van hun actieve SSH-sleutels. Dit is niet zozeer een gebrek aan discipline binnen de organisatie, maar eerder een gevolg van een ontwerp dat niet is afgestemd op de schaal en snelheid van moderne infrastructuren. SSH werd voor het eerst ontwikkeld halverwege de jaren negentig, toen het typische gebruiksscenario bestond uit een systeembeheerder die een kleine set servers beheerde; SSH-2 werd in 2006 formeel gestandaardiseerd als een IETF-protocol (RFC's 4250-4254).

Het authorized_keys-bestand was een oplossing voor menselijke schaal. Op bedrijfsniveau, met honderden servers, een dynamische infrastructuur en CI/CD-pipelines die continu sleutels genereren, is het een onbeheersbare opslagplaats voor inloggegevens zonder ingebouwde levenscycluscontroles. De gevolgen voor de beveiliging en de financiën zijn goed in kaart gebracht.

Volgens het IBM-rapport '2025 Cost of a Data Breach' bedraagt ​​het wereldwijde gemiddelde $ 4.44 miljoen. Datalekken die worden veroorzaakt door gestolen inloggegevens kosten gemiddeld $ 4.67 miljoen en het duurt 246 dagen om ze te identificeren en in te dammen – een van de langste levenscycli van alle aanvalsvectoren. Het '2025 Data Breach Investigations Report' van Verizon toonde aan dat gestolen inloggegevens de belangrijkste initiële toegangsvector waren in 22% van alle datalekken, meer dan welke andere aanvalscategorie dan ook. SSH-sleutels, die persistent zijn, brede privileges bieden en vaak niet worden gecontroleerd, zijn precies het type inloggegevens dat deze statistieken mogelijk maakt.

Hoe tijdelijke SSH-sleutels werken: het technische mechanisme

Tijdelijke SSH-sleutels zijn cryptografische sleutelparen met een korte levensduur die op aanvraag voor een specifieke sessie worden gegenereerd en automatisch ongeldig worden wanneer die sessie wordt afgesloten. Het beveiligingsvoordeel ten opzichte van statische sleutels zit niet in het algoritme, dat identiek is, maar volledig in de levenscyclus. Een tijdelijke SSH-sleutel wordt aangemaakt voor een afgebakend doel en verliest zijn geldigheid zodra dat doel is bereikt.

Het mechanisme waarmee tijdelijke SSH-sleutels naar een doelserver worden verzonden, verschilt per implementatie. De twee meest voorkomende benaderingen zijn dynamisch beheer van authorized_keys en OpenSSH-authenticatie op basis van certificatenelk met eigen afwegingen op het gebied van beveiliging en werking.

Dynamisch beheer van geautoriseerde sleutels

Het sleutelbeheerplatform genereert een nieuw sleutelpaar op het moment dat een sessie wordt aangevraagd. De publieke sleutel wordt alleen voor de duur van de sessie naar authorized_keys op de doelservver geschreven en direct verwijderd zodra de sessie is beëindigd of de geldigheidsperiode is verlopen. De gebruiker hoeft niets op te ruimen. Deze aanpak werkt met standaard OpenSSH-configuraties zonder extra agents op de doelhosts.

OpenSSH-authenticatie op basis van certificaten

OpenSSH ondersteunt een certificaat autoriteit model (gedefinieerd in de OpenSSH PROTOCOL.certkeys-specificatie, met algoritmespecifieke certificaattypen zoals [e-mail beveiligd] en [e-mail beveiligd]) waarbij een vertrouwde CA kortstondige gebruikerscertificaten ondertekent die de SSH-server accepteert in plaats van individuele authorized_keys-vermeldingen. De server vertrouwt elk certificaat dat door de CA is ondertekend gedurende de geldigheidsperiode, die kan worden ingesteld op minuten.

Wanneer het certificaat verloopt, wordt de toegang automatisch ingetrokken. Deze aanpak vereist dat de SSH-server zo geconfigureerd wordt dat deze de publieke sleutel van de CA vertrouwt via de TrustedUserCAKeys-richtlijn, maar het elimineert het beheer van authorized_keys per server. Het schaalt aanzienlijk beter bij grote serverparken.

In beide modellen activeert het sessieverzoek een nieuwe verificatiecyclus: identiteitsverificatie, beleidsevaluatie en sleuteluitgifte, afgestemd op het goedgekeurde tijdsvenster. Wanneer de sessie eindigt, eindigt de toegang. Er is geen verdere opschoning op de doelservver nodig dan wat het platform automatisch afhandelt.

Directe vergelijking: statische SSH-sleutels versus tijdelijke sleutels

Kenmerk	Statische SSH-sleutels	Kortstondige sleutels
houdbaarheid	Mogelijk onbeperkt geldig; geldig tot handmatige intrekking.	Verloopt automatisch aan het einde van de sessie of het tijdsvenster.
herroeping	Handmatige verwijdering in elk authorized_keys-bestand	Geen herroepingsstap; ongeldigverklaring is automatisch.
Authenticatiemodel	Vertrouwen wordt eenmalig gevestigd bij het aanmaken van de sleutel; het wordt voor altijd hergebruikt.	Het vertrouwen wordt bij elke sessieaanvraag opnieuw geverifieerd.
Controlespoor	Alleen IP-adres en sleutelvingerafdruk; geen identiteitstracering mogelijk.	Volledig sessielogboek gekoppeld aan een geverifieerde identiteit
Staande toegang	Ja, persistent, ongeacht beleids- of rolveranderingen.	Nee, toegang is alleen mogelijk voor de geautoriseerde sessie.
Zijwaarts bewegingsvenster	Mogelijk oneindig lang als de sleutel niet wordt gedetecteerd.	Minuten tot uren, begrensd door het sessievenster.
offboarden	Handmatige verwijdering van sleutels; vaak onvolledig.	Toegang wordt automatisch beëindigd; er is geen opruimactie per server nodig.

Tijdelijke SSH-sleutels en Zero Trust-architectuur

De Zero Trust-architectuur, zoals gedefinieerd in NIST Special Publication 800-207, vereist dat elk toegangsverzoek wordt geverifieerd en geautoriseerd op basis van het geldende beleid op het moment van het verzoek, en niet op basis van een vertrouwensrelatie die eerder is opgebouwd. Het vereist continue verificatie, geen impliciet vertrouwen gebaseerd op eerdere toegang.

Statische SSH-sleutels zijn structureel onverenigbaar met deze vereiste. Ze vestigen eenmalig vertrouwen bij het aanmaken van de sleutel en behouden dit voor onbepaalde tijd, ongeacht wijzigingen in de werkstatus van de gebruiker, de apparaatstatus of het huidige toegangsbeleid. Permanente toegang, persistent en niet-geverifieerd, is hun standaard werkingsmodus.

Tijdelijke SSH-sleutels sluiten van nature aan bij het Zero Trust-principe. Elk sessieverzoek activeert een nieuwe identiteitsverificatie en beleidsevaluatie. Toegang wordt alleen verleend als alle controles succesvol zijn, alleen voor de goedgekeurde duur, en eindigt automatisch wanneer die periode is verstreken. Er is geen permanent privilege dat kan worden gecompromitteerd en geen permanente inloggegevens die kunnen worden gestolen.

Het CrowdStrike 2026 Global Threat Report toonde aan dat de gemiddelde tijd die nodig is om een ​​cyberaanval uit te voeren in 2025 daalt naar 29 minuten, met de snelste waargenomen aanval in slechts 27 seconden; bij één inbraak begon de data-exfiltratie al binnen vier minuten na de eerste toegang. Een statische SSH-sleutel die jarenlang geldig is, geeft aanvallers alle tijd die ze nodig hebben. Een tijdelijke SSH-sleutel die slechts enkele minuten geldig is, biedt die tijd niet. Dit is de reden waarom organisaties die overstappen op een statische SSH-sleutel deze aanpak overwegen. Zero Trust-beveiligingsframeworks Steeds vaker beschouwen ze SSH-sleutelbeheer als een kernonderdeel van hun strategie voor bevoorrechte toegang.

Beveiligingsoverwegingen

Het beheer van tijdelijke SSH-sleutels verbetert de beveiliging van SSH-toegang aanzienlijk. De implementatie brengt echter eigen vereisten met zich mee waaraan moet worden voldaan om de architectuur stabiel te houden.

• Beveiliging van het uitgifteplatform: Het gecentraliseerde platform voor sleuteluitgifte is een cruciaal beveiligingsonderdeel. Het moet robuust, zeer beschikbaar en met dezelfde strengheid beheerd worden als elk ander systeem met geprivilegieerde toegang. Een inbreuk op het uitgifteplatform heeft grotere gevolgen dan een inbreuk op individuele statische sleutels, omdat het alle sessies beïnvloedt in plaats van slechts één inloggegeven.
• Belangrijkste informatie alleen in het geheugen: Het tijdelijke sleutelmateriaal aan de clientzijde mag alleen tijdens de sessie in het geheugen aanwezig zijn. Elke implementatie die de privésleutel naar de schijf schrijft, introduceert opnieuw het persistentierisico dat juist met tijdelijke SSH-sleutels moet worden voorkomen. Controleer of de client het geheugen expliciet wist na afloop van de sessie.
• Grootte van het geldigheidsvenster: De geldigheidsperioden moeten worden afgestemd op de werkelijke operationele behoeften in plaats van op een handige standaardwaarde. Een onderhoudstaak van 20 minuten mag geen sleutel hebben die 8 uur geldig is. Controleer de configuratie van de geldigheidsperioden regelmatig en eis een expliciete rechtvaardiging voor verzoeken om verlengde toegang.
• Pijpleidingbewaking: Monitor het uitgifteproces op afwijkende patronen: pieken in het volume, toegang vanaf onverwachte bronadressen of verzoeken buiten de normale werktijden. Dit zijn belangrijke signalen, zelfs als individuele toegangsbeslissingen technisch gezien correct lijken, omdat ze kunnen wijzen op een compromittering van een account.
• Parallelle statische sleutelherstelprocedure: Verouderde statische sleutels mogen niet in authorized_keys blijven staan ​​naast de nieuwe workflow voor tijdelijke sleutels. Het opsporen en herstellen van de bestaande sleutelstructuur moet parallel lopen met de implementatie van tijdelijke SSH-sleutels. Een hybride situatie zonder een tijdlijn voor herstel heft een groot deel van de beveiligingsverbetering op.

Hoe SSH Secure tijdelijk SSH-sleutelbeheer implementeert

At Encryptie ConsultingWij begrijpen de uitdagingen waar bedrijven voor staan ​​bij het beheren van SSH-sleutels op grote schaal. Onze oplossing, SSH beveiligd, is ontworpen om end-to-end beveiliging van de sleutellevenscyclus te bieden en uitgebreid inzicht te verschaffen, zodat organisaties sleutels met vertrouwen en zonder extra complexiteit kunnen beheren. Zo helpen we:

1. Gecentraliseerde zichtbaarheid en eigendomstoewijzing

Door een combinatie van agentgebaseerde en agentloze detectie lokaliseert SSH Secure elke SSH-sleutel op servers en gebruikerscomputers. Alle sleutels worden opgeslagen in één inventaris met details over eigendom en gebruik. Dit elimineert overbodige sleutels, vermindert wildgroei en zorgt voor volledige verantwoording binnen de omgeving.

2. Veilige toegangscontrole en het gebruik van sessiegebonden sleutels

Gedetailleerde rolgebaseerde toegangscontrole (RBAC) zorgt ervoor dat gebruikers alleen de minimaal vereiste toegang krijgen. Voor gevoelige of tijdelijke bewerkingen geeft SSH Secure tijdelijke sessiegebonden sleutels uit die automatisch verlopen. Samen handhaven deze controles het principe van minimale privileges en minimaliseren ze de impact van gecompromitteerde inloggegevens, indien van toepassing.

3. Geautomatiseerde sleutellevenscyclusorkestratie

SSH Secure automatiseert de volledige levenscyclus van sleutels, inclusief beveiligde generatie, beleidsgestuurde rotatie, geplande vervaldatum en intrekking. Levenscyclusbeheer elimineert zwakke of verouderde sleutels, vermindert menselijke tussenkomst en zorgt voor continue naleving van best practices in de branche.

4. HSM-geïntegreerde bescherming

Alle privésleutels zijn beveiligd binnen HSM'swaardoor niet-exporteerbaarheid en manipulatiebestendigheid worden gegarandeerd. Sleutels worden gegenereerd met behulp van sterke cryptografische algoritmen zoals RSA-4096, ECDSAen Ed25519, die zowel sterke bescherming en weerstand tegen brute-force-aanvallen als efficiëntie bieden.

5. Beleidsgestuurde controle voor belangrijke activiteiten

Alle belangrijke bewerkingen, zoals het genereren, goedkeuren, roteren en intrekken van workflows, worden afgedwongen via beleidgebaseerde controles. Dit zorgt voor consistentie in de omgeving, vermindert handmatige fouten en handhaaft organisatiebrede beveiligingsnormen. Beleid kan worden aangepast aan wettelijke vereisten of worden aangepast ter ondersteuning van interne governancemodellen.

6. Continue monitoring, audits en paraatheid voor naleving

SSH Secure biedt realtime monitoring van belangrijke activiteiten met gedetailleerde gebeurtenisregistratie en ingebouwde anomaliedetectie. Logs kunnen worden geïntegreerd met Splunk of Loki-Grafana dashboards voor geavanceerde visualisatie, correlatie en waarschuwingen. Flexibele auditmogelijkheden omvatten downloadbare logs en gedetailleerde rapporten, waardoor beveiligingsteams duidelijk inzicht krijgen in sleutelgebruik en de algehele status. Gecentraliseerde auditing met beleidsgebaseerde waarschuwingen maakt proactief beveiligingsbeheer, snelle detectie van afwijkingen en snellere respons op incidenten mogelijk.

Conclusie

Statische SSH-sleutels vormen al decennia een essentieel onderdeel van de infrastructuur van bedrijven. Ze behoren echter ook tot de meest systematisch onbeheerde inloggegevens in moderne beveiligingsprogramma's. Ze hopen zich op in de infrastructuur, blijven oneindig lang bestaan ​​en bieden bevoorrechte toegang lang nadat de gebruikers en systemen waarvoor ze zijn aangemaakt, niet meer gebruikt worden.

De gegevens over ongebruikte root-toegangssleutels, het onderzoek waaruit blijkt dat 60 tot 90% van de organisaties geen volledig SSH-sleuteloverzicht heeft, en de bevindingen van het Ponemon Institute over de kosten van inbreuken op bevoorrechte toegang documenteren de gevolgen van een ontwerp voor inloggegevens dat nooit is gemaakt voor bedrijfsbrede schaal.

kortstondig SSH-sleutels lossen het structurele probleem direct op. Toegang wordt op aanvraag gegenereerd, gekoppeld aan een geverifieerde identiteit, geautoriseerd volgens het geldende beleid en automatisch ongeldig gemaakt wanneer de sessie eindigt. Offboarding wordt een beleidsgebeurtenis. Het auditspoor wordt compleet en gekoppeld aan de identiteit, in plaats van beperkt tot IP-adressen en sleutelvingerafdrukken.

Voor meer informatie over hoe SSH Secure de wildgroei aan SSH-sleutels aanpakt en de uitgifte van tijdelijke SSH-sleutels voor bevoorrechte toegang ondersteunt, of om uw huidige omgeving te bespreken, Neem contact op met Encryption Consulting..