För mig blir SSH-certifikat värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. SSH-certifikat flyttar tillitsbeslutet från hundratals individuella nyckelposter till en kontrollerad CA som kan utfärda kortlivade identiteter.
SSH-certifikat i praktiken
Första byggstenen: Host certificates kan minska behovet av manuellt hanterade known_hosts-poster. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: User certificates kan bära principals som motsvarar roller. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Kort giltighetstid begränsar värdet av en stulen certifikatsfil. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: CA-nyckeln blir en mycket känslig tillgång som bör skyddas separat. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Designa principals och giltighetstider före implementation.
- Skydda CA-nyckeln och separera online-utfärdande från root of trust där det behövs.
- Konfigurera klienter och servrar att lita på rätt CA.
- Utfärda ett kortlivat testcertifikat.
- Planera revocation eller snabb borttagning av principals.
För SSH-certifikat håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett testbart exempel
I en labbmiljö med många kortlivade servrar är det enklare att lita på en host-CA än att hantera fingerprint för varje ny nod. Samma princip kan göra automatisk provisioning renare.
När en bra idé blir fel i drift
- Att göra CA:n till en oskyddad fil på samma adminlaptop.
- Att använda långa giltighetstider som återskapar problemet med statiska nycklar.
- Att blanda host- och user-CA utan tydlig ansvarsfördelning.
Efterkontroll
För SSH-certifikat vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Certifikatet accepteras endast under sin giltighetstid.
- Fel principal nekas.
- En host kan bytas utan att klienternas individuella host keys måste distribueras manuellt.
Ett negativt test hör också till SSH-certifikat: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
SSH-certifikat – när central tillit fungerar bättre än en djungel av authorized_keys handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.