Een SSH-sleutelwachtzin beschermt het bestand, niet de route

Een back-upschijf van een oude laptop bevat nog steeds een privé-SSH-sleutel, en iemand vraagt of de VPN die beschermt. Dat doet hij niet, en dat heeft hij nooit gedaan. De VPN beschermt een pad tussen twee netwerken; de wachtzin beschermt het bestand; de agent beschermt een lopende sessie. Drie verschillende mechanismen, drie verschillende faalwijzen, en een gestolen kopie geeft alleen om de eerste twee.

De wachtzin hoort bij het bestand

Een SSH-sleutelwachtzin versleutelt het privésleutelmateriaal in rust. Het is niet het accountwachtwoord dat naar de server wordt gestuurd, en het is niet de inloggegevens waarmee je bij de VPN komt. Ze verwarren leidt tot wijzigingen die de blootstelling niet aanpakken.

De ssh-keygen-handleiding van OpenSSH behandelt het omgaan met wachtzinnen, inclusief de schakelaar -p die een nieuwe wachtzin op een sleutel zet die al bestaat.

Voor een bestaande sleutel is de vorm van de opdracht eenvoudig, en hij herschrijft het bestand:

ssh-keygen -p -f ~/.ssh/id_ed25519

Gebruik het goedgekeurde onderhouds- en herstelproces van de sleuteleigenaar, want dit is een schrijfactie, geen inspectie. Publiceer het privébestand niet en zet geen echte wachtzin op een gedeelde opdrachtregel. Een wachtzinwijziging versleutelt een eerder gemaakte kopie niet opnieuw. Leg de locatie van de oude kopie vast in het ticket, zodat de eigenaar kan beslissen of die vernietigd moet worden.

Een kopie overleeft de laptop en de tunnel

Zodra een sleutelbestand is gekopieerd, zegt de actieve VPN-verbinding van de laptop er niets meer over. Wat telt, is hoe goed het bestand zelf is beschermd, en welke servers de bijbehorende publieke sleutel nog vertrouwen.

De wachtzin van het huidige bestand wijzigen raakt de kopie niet, en haalt dezelfde publieke sleutel niet uit authorized_keys op een server. Intrekking en herversleuteling zijn aparte acties.

Behandel een uitgelekte privésleutel dus als een identiteitsgebeurtenis, niet als een netwerkgebeurtenis. Verwijder of vervang de geaccepteerde sleutel via de servers en het inschrijfproces die hem bezitten. De VPN stoppen beperkt één route op één moment; het is geen intrekking.

Ontgrendelen verplaatst het geheim naar een agent

Een agent houdt ontsleutelde identiteiten voor latere authenticatie, zodat de gebruiker de wachtzin niet bij elke verbinding opnieuw invoert. Dat is een gebruiksgemak met een eigen beveiligingsgrens.

ssh-agent kan met zijn -t-optie beperken hoe lang een identiteit geladen blijft, en een instelling per identiteit kan die grens overschrijven. Kies het beleid voor de agent die je werkelijk draait in plaats van aan te nemen dat een VPN-verbreking elke geladen sleutel vergeet.

Een proces dat wordt gecompromitteerd nadat de sleutel is ontgrendeld, is een ander probleem dan een gestolen versleuteld bestand. De agent doorsturen naar een andere host delegeert authenticatievermogen zonder het sleutelbestand te kopiëren, dus schakel het alleen in voor een goedgekeurde behoefte.

Noem wat de agent op dit moment vasthoudt, voor en na een wijziging:

ssh-add -l

Onbeheerde taken hebben hun eigen plan nodig

Een geplande taak kan geen prompt beantwoorden. Die heeft een goedgekeurde regeling voor machine-inloggegevens nodig, en het ontgrendelingsgeheim in dezelfde map als de sleutel houden, leesbaar voor hetzelfde account, maakt geen tweede grens.

Werk met de diensteigenaar aan ondersteunde geheimlevering of hardwarematige werking, en dek vernieuwing, storing en herstel. Een mens achter het toetsenbord willen verandert hoe een storing eruitziet vergeleken met een host die opstart zonder dat iemand meekijkt.

Houd ook de hostidentiteitscontrole van de server en zijn accountbeperkingen aan. Een VPN-route geeft je een privépad; hij bewijst niet dat elke SSH-listener die je bereikt de host is die je bedoelde. Leg de listener en de vingerafdruk van de hostsleutel vast in dezelfde inventaris als de sleutel zelf.

Verifieer de grenzen afzonderlijk

Test elke grens met zijn eigen vraag. Gaat het bestand open zonder de wachtzin? Houdt de agent de identiteit na een verbreking? Accepteert de server de publieke sleutel nog?

Twee opdrachten beantwoorden de eerste en de derde:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Leg bestandsbescherming, toegestaan sleutelgebruik en verwijdering aan de serverkant vast als drie afzonderlijke regels. Een tunnel, een wachtzin en een agent bewaken elk een ander deel van de relatie, en slechts één ervan gaat over het netwerk.