Er staat nog een oude beheerderssleutel in de projectmap. Hij werkt op meerdere servers, maar niemand weet precies wie een kopie heeft. De overstap van wachtwoorden naar SSH-sleutels heeft de aanmelding veranderd zonder de verantwoordelijkheid te verduidelijken.
Goed SSH-beheer verbindt individuele identiteiten, passende rechten op doelsystemen en betrouwbare intrekking. Afhankelijk van de omgeving kunnen onderhouden publieke sleutels met een degelijke inventaris volstaan. Grotere of vaak veranderende omgevingen kunnen baat hebben bij kort geldige SSH-certificaten. Beide aanpakken vragen om uitvoerbaar beheer.
Vier zaken die niet verward moeten worden
De privésleutel van de gebruiker maakt het mogelijk de eigen identiteit te bewijzen. Hij wordt beschermd bewaard en niet via chat, e-mail of een onbeschermde projectmap verspreid. De bijbehorende publieke sleutel kan op de bedoelde doelsystemen worden vastgelegd om toegang toe te staan. De vingerafdruk helpt bij een eenduidige koppeling in de inventaris.
De hostsleutel identificeert juist de benaderde server. Hostcontrole voorkomt dat een verbinding ongemerkt bij de verkeerde tegenpartij uitkomt. Een SSH-certificaat voegt een ondertekende verklaring aan een publieke sleutel toe, bijvoorbeeld over identiteit en geldigheid. OpenSSH-certificaten hebben een eigen formaat en zijn geen gewone TLS-/X.509-certificaten.
Persoonlijke aanmeldingen en technische taken scheiden
Beheertaken worden aan personen en hun toegestane werkzaamheden gekoppeld. Een gedeelde, langdurig geldige rootsleutel maakt vertrek, rotatie en traceerbaarheid onnodig lastig. Individuele aanmeldingen met passend geregelde beheerrechten bieden een betere basis.
Een back-up- of deploymenttaak heeft een eigen technische identiteit met vastgelegde verantwoordelijkheid nodig. Waar mogelijk wordt de toegang beperkt tot de bedoelde functie, bijvoorbeeld met een verplicht commando en passende doorstuurregels. De privésleutel van een medewerker mag niet ongemerkt een blijvende voorwaarde voor een automatische taak worden.
Van sleutelinventaris naar kort geldige certificaten
Bij weinig systemen kan gecontroleerde verspreiding van publieke sleutels volstaan. De inventaris vermeldt persoon of dienst, vingerafdruk, doelsystemen, reikwijdte en geplande controle- of vervangingsdatum. Doorslaggevend is dat rechten op alle betrokken doelen betrouwbaar worden onderhouden.
Een SSH-certificaatautoriteit kan in plaats daarvan publieke sleutels voor een beperkte periode en vastgelegde identiteiten ondertekenen. De servers vertrouwen de aangewezen CA en toetsen hun overige regels. De private aanmeldsleutel hoeft niet naar de CA te worden gestuurd. De CA-sleutels en uitgifteregels worden extra beschermd.
Korte geldigheid beperkt de gebruiksduur van een uitgegeven bewijs. Zij beëindigt geen bestaande sessie en vervangt geen intrekkingsprocedure. Na vertrek moet ook de uitgifte van nieuwe certificaten worden geblokkeerd. Een centraal secretsplatform is een mogelijke beheervorm; het moet de bedoelde SSH-werkwijze daadwerkelijk ondersteunen.
| Beheeraanpak | Geschikt voor | Wat beheer vraagt |
|---|---|---|
| Publieke sleutels onderhouden | Een overzichtelijke, goed geïnventariseerde verzameling doelsystemen. | Verspreiding, verwijderen van oude rechten en vervanging bij afwezigheid. |
| SSH-certificaten uitgeven | Beperkte geldigheid en vastgelegde identiteiten. | CA-bescherming, uitgifteregels, serververtrouwen en intrekking. |
| Technische identiteiten | Automatisering met een duidelijke taak. | Beperkte doelrechten, verantwoordelijkheid en rotatieprocedure. |
| Agent of hardwaresleutel | Passende persoonlijke aanmeldmethoden. | Doorstuurbeperkingen, versiecontrole en herstel. |
Agents en hardwaresleutels bewust inzetten
Een SSH-agent maakt aanmelding met geladen sleutels mogelijk zonder het privésleutelbestand naar elke doelserver te kopiëren. Agent forwarding geeft een systeem op afstand echter toegang tot de ondertekenmogelijkheden. OpenSSH waarschuwt expliciet dat een aanvaller met voldoende toegang tot dat systeem geladen identiteiten kan gebruiken om zich aan te melden zonder het sleutelmateriaal uit te lezen.
Agent forwarding wordt daarom alleen voor het benodigde pad ingesteld. Ondersteunde tijd- of doelbeperkingen kunnen aanvullende grenzen stellen. Hardwarebeveiligingssleutels zijn een andere optie voor passende interactieve toegang. Client, server, sleuteltype en aanraak- of PIN-eisen moeten bij elkaar passen; een onbewaakte taak heeft andere behoeften dan een persoonlijke aanmelding.
Rotatie en intrekking moeten het doel bereiken
Een sleutel vervangen op de notebook verwijdert oude toegang nog niet van de server. Bij vastgelegde publieke sleutels moeten rechten op alle betrokken doelen worden bijgewerkt. Certificaten kunnen daarnaast intrekkingsmechanismen zoals OpenSSH Key Revocation Lists gebruiken. Intrekking werkt pas wanneer de bedoelde servers haar correct toepassen.
De procedure omvat ook een verloren apparaat, een gecompromitteerde sleutel en een uitgevallen beheerdienst. Onafhankelijke noodtoegang wordt beschermd, vastgelegd en gecontroleerd getest. Herstel mag niet afhangen van precies het toegangspad dat is uitgevallen.
Linux- en Proxmox-omgevingen afzonderlijk beoordelen
In gemengde omgevingen worden versies en werkelijk ondersteunde OpenSSH-functies vastgelegd. Een actuele handleiding garandeert niet dat elke Linux-installatie dezelfde opties biedt. Nieuwe regels worden ingevoerd met een aangewezen testtoegang en een gecontroleerde terugweg.
Proxmox VE gebruikt SSH ook voor eigen clusterfuncties, waaronder bepaalde console-, migratie- en replicatiepaden. Deze technische vertrouwensrelaties worden apart beoordeeld van persoonlijke beheerderstoegang. Het algemeen opschonen of overschrijven van sleutelbestanden kan de werking verstoren. Wijzigingen worden daarom getoetst aan de documentatie van de geïnstalleerde versie.
Wat een overzichtelijke eerste stap omvat
DAXS inventariseert bestaande SSH-toegang, koppelt verantwoordelijkheden en plant passend beheer. De pilot test aanmelding, rechten, intrekking, logging en herstel. Een geslaagde aanmelding alleen is onvoldoende als acceptatiecriterium. Alleen aanmeldlogs vormen ook niet automatisch een volledige registratie van alle uitgevoerde commando’s.
De infrastructuurdiensten en het artikel over Proxmox in bedrijven geven de beheercontext. Voor gedeelde portalen vult het artikel over kluizen, rollen en offboarding dit aan. U kunt een inventarisatie van beheerderstoegang aanvragen.
Veelgestelde vragen
Mag ik een publieke sleutel delen?
Het publieke deel is bedoeld voor passende verspreiding. De koppeling aan de juiste persoon en het juiste doel moet wel worden gecontroleerd. Het private deel blijft beschermd en wordt niet als gedeeld toegangsbestand rondgestuurd.
Volstaat een kort geldig certificaat voor directe intrekking?
Nee. Uitgifte, resterende geldigheid, intrekkingscontrole en bestaande sessies moeten samen worden beoordeeld. Een korte looptijd vervangt dit proces niet.
Is een centrale certificaatautoriteit altijd nodig?
Nee. Omvang, veranderfrequentie, automatisering en beheercapaciteit bepalen de passende oplossing. Goed onderhouden sleutelbeheer kan geschikt zijn voor een overzichtelijke omgeving.
Bronnen: OpenSSH: aanmelding en geautoriseerde sleutels (externe link) · OpenSSH: certificaten en intrekkingslijsten (externe link) · OpenSSH: vertrouwens- en intrekkingsregels op de server (externe link) · OpenSSH: agent forwarding (externe link) · OpenSSH: agentsleutels en beperkingen (externe link) · Proxmox VE: beheerhandleiding, SSH in het cluster (externe link)
Conceptuele toelichting; concrete functies hangen af van geïnstalleerde versies en gepland beheer.
