SSH-nycklar vs SSH-certifikat: Vad skillnaden egentligen betyder

Både SSH-nycklar och SSH-certifikat autentiserar användare och system med hjälp av kryptografi med offentlig nyckel , men förlitar sig på fundamentalt olika förtroendemodeller. SSH-nycklar upprättar förtroende genom att placera auktoriserade offentliga nycklar i varje servers authorized_keys-fil; SSH-certifikat använder en betrodd certifikatutfärdare (CA) för att verifiera identiteter och bevilja tidsbunden åtkomst centralt. Den skillnaden påverkar varje steg i autentiseringsuppgifternas livscykel: hur åtkomst beviljas, hanteras, granskas och återkallas, särskilt i takt med att miljöer växer. Rekommenderad åtgärd: styr SSH-nycklar med centraliserad inventering, rotation och återkallelse för miljöer där nycklar är praktiska; utvärdera certifikatbaserad autentisering för miljöer där nyckelinventeringen har vuxit bortom vad manuell hantering kan spåra.

Snabbt svar: SSH-nycklar vs SSH-certifikat

SSH-nycklar: varje server litar oberoende av varandra på publika nycklar som listas i dess authorized_keys-fil. Inget utgångsdatum. Ingen central post. Åtkomst kvarstår tills den manuellt tas bort från varje server. SSH-certifikat: servern litar på en certifikatutfärdare; certifikatutfärdaren garanterar identiteter genom att signera certifikat med giltighetsfönster, huvudnamn och valfria begränsningar. Åtkomsten upphör automatiskt när giltighetsfönstret stängs. Skillnaden mellan de två är inte kryptografisk styrka; det är vad som händer med åtkomsten över tid allt eftersom team, system och autentiseringsuppgifter ackumuleras. För en fullständig efterlevnadskartläggning av SSH-nyckelhantering, se Efterlevnad av SSH-nyckelhantering . För rotationsramverket, se Utforma en effektiv SSH-nyckelrotationspolicy.

Ackumuleringsproblemet: Varför skillnaden spelar roll

Den operativa effekten av dessa olika förtroendemodeller blir uppenbar allt eftersom miljöerna växer. Problemet uppstår inte som en enskild händelse. Det ackumuleras. En ingenjör ansluter sig och deras nyckel läggs till ett dussin servrar. En entreprenör slutför sitt engagemang och deras nyckel tas inte bort eftersom ingen spårade vilka servrar den fanns på. Automatiseringspipelines genererar nyckelpar som överlever de pipelines de byggdes för. Tre år senare finns hundratals nycklar i serverinfrastrukturen utan någon tillförlitlig inventering av vem som äger dem.

Branschundersökningar rapporterade att 57 % av organisationerna ansåg det smärtsamt och svårt att hantera SSH-nycklar, och även om medvetenheten har förbättrats kvarstår den underliggande operativa risken med ohanterade nycklar oavsett hur väl problemet identifieras. Det som gör detta svårt att upptäcka tidigt är att ingenting uppenbarligen går sönder. Servrar svarar, pipelines körs, distributioner slutförs. Åtkomstproblemet är osynligt tills det dyker upp som en säkerhets- eller efterlevnadshändelse.

Det är här skillnaden mellan SSH-nycklar och SSH-certifikat blir viktig. Båda erbjuder stark autentisering, men deras förtroendemodeller avgör hur förtroendet upprätthålls, utökas och återkallas över tid. Att förstå de strukturella skillnaderna gör det möjligt för organisationer att välja rätt modell för sin miljö och styrningsmognad.

Vad är SSH-nycklar?

En SSH- nyckel är ett kryptografiskt länkat par: en privat nyckel och en publik nyckel, genererade tillsammans som en matchande uppsättning. De tjänar ett enda syfte: att bevisa identitet utan att skicka ett lösenord över nätverket.

Den privata nyckeln finns kvar på den maskin den skapades på. Den får aldrig kopieras, delas eller överföras. Det är den enda filen som kan slutföra en autentiseringsutmaning från servern, och dess säkerhet är hela grunden för förtroende.

Den publika nyckeln distribueras till servrar där åtkomst behövs. På varje server lagras den i filen authorized_keys (vanligtvis ~/.ssh/authorized_keys för målanvändarkontot). Denna fil är en lista: en publik nyckel per rad, där varje nyckel representerar en enhet som servern kommer att autentisera.

Säkerheten kommer från asymmetrisk kryptografi : den privata nyckeln genererar en kryptografisk signatur som endast motsvarande publika nyckel kan verifiera. Att känna till den ena innebär inte att man kan härleda den andra; en giltig signatur kan endast produceras av innehavaren av den privata nyckeln.

Hur SSH-nyckelautentisering fungerar

Autentiseringssekvensen fastställer identitet utan att överföra den privata nyckeln:

1. Användarens publika nyckel placeras i filen authorized_keys på målservern (av en administratör, av användaren om de har serveråtkomst eller genom automatiserad provisionering).
2. Användaren initierar en anslutning. SSH klienten signalerar vilken offentlig nyckel den avser att använda för autentisering.
3. Servern kontrollerar sin authorized_keys-fil. Om den skickade publika nyckeln finns och är tillåten för målanvändarkontot fortsätter servern med autentiseringen.
4. Klienten signerar autentiseringsbegäran med sin privata nyckel och skickar den signerade begäran till servern. Den privata nyckeln lämnar aldrig klienten.
5. Servern verifierar signaturen med den lagrade publika nyckeln. En giltig signatur bekräftar att klienten innehar motsvarande privata nyckel. Autentiseringen lyckas.

Förtroendemodellen: servern litar på SSH-nyckeln eftersom den listas i authorized_keys. Förtroendet har inget utgångsdatum och ingen central post. Det kvarstår tills någon manuellt tar bort nyckeln från filen på varje server där den distribueras.

De operativa utmaningarna med SSH-nyckelhantering

Själva autentiseringsprocessen är säker. Utmaningarna uppstår i hur förtroende etableras och upprätthålls i stor skala:

• Varje server har sin egen authorized_keys-fil. Varje publik nyckel som behöver åtkomst måste läggas till, uppdateras eller tas bort individuellt på varje server.
• SSH-nycklar har ingen inbyggd utgångsdatum. En offentlig nyckel förblir betrodd tills den manuellt tas bort från varje server där den installeras.
• Utan en centraliserad lager, organisationer kämpar med att avgöra vem som äger en nyckel, varför den användes, om den fortfarande används och om den ska fortsätta att existera.
• Nycklar som skapats för tillfälliga projekt, entreprenörer eller automatiseringsarbetsflöden kan förbli aktiva långt efter att deras syfte har upphört, vilket utökar attackytan i tysthet.

Dessa begränsningar är inte svagheter i SSH-kryptografi. De är en konsekvens av en decentraliserad förtroendemodell där varje server självständigt bestämmer vilka publika nycklar som ska litas på. Allt eftersom miljöer skalas upp letar organisationer efter sätt att centralisera förtroendebeslut, minska manuell administration och förbättra synligheten. SSH-certifikat utformades för att hantera dessa operativa utmaningar. För relaterad vägledning om hur man hanterar SSH-nycklar i stor skala, se Hur SSH-nyckelhantering stärker säkerheten och Säkrar SSH-nycklar med HSM:er.

Vad är SSH-certifikat?

Ett SSH-certifikat är en offentlig nyckel som signeras av en betrodd certifikatutfärdare (CA). CA:ns signatur binder identitets- och åtkomstinformation till nyckeln, vilket skapar en verifierbar autentiseringsuppgift med inbäddad utgångsdatum. Till skillnad från en fristående offentlig nyckel som inte innehåller någon ägarinformation innehåller ett SSH-certifikat:

• Nyckel-ID: en godtycklig sträng som tilldelas vid signeringstillfället och som identifierar certifikatet i loggar och granskningsregister. Organisationer använder användarnamn, e-postadresser, medarbetar-ID:n eller ärendenummer.
• Lista över rektorer: de identiteter som certifikatet är auktoriserat att representera. För användarcertifikat motsvarar principaler operativsystemets användarnamn som ubuntu, ec2-user eller admin.
• Giltighetsfönster: En tidsstämpel för giltigt efter och giltigt före (Unix-tidsstämplar) som tillämpas under autentisering. När den aktuella tiden faller utanför detta fönster avvisas certifikatet automatiskt.
• Tillägg: funktioner som permit-pty (terminalåtkomst), permit-port-vidarebefordran eller permit-agent-vidarebefordran.
• Kritiska alternativ: påtvingade begränsningar som att begränsa certifikatet till specifika käll-IP-adresser eller begränsa sessionen till ett enda kommando.
• CA-signatur: CA:s kryptografiska signatur över allt ovanstående, vilket förhindrar manipulering utan att ogiltigförklara certifikatet.

SSH-certifikatformatet som används av OpenSSH är inte detsamma som X.509 -formatet som används för HTTPS. Det är ett specialbyggt format som definieras i OpenSSH PROTOCOL.certkeys-specifikationen. Själva CA:n är helt enkelt ett SSH-nyckelpar på en skyddad plats: dess privata nyckel signerar användar- och värdcertifikat; dess publika nyckel distribueras en gång till varje server. Från och med den tidpunkten kan alla servrar som är konfigurerade att lita på CA:n autentisera certifikat som signerats av den CA:n.

Så fungerar SSH-certifikatautentisering

Autentiseringssekvensen skiljer sig från nyckelbaserad autentisering i hur förtroende upprättas. Istället för att kontrollera om den anslutande nyckeln finns listad på den specifika servern kontrollerar servern om certifikatet har signerats av en CA som den litar på :

1. Ett CA-nyckelpar genereras och dess publika nyckel distribueras till varje server en gång med hjälp av TrustedUserCAKeys-direktivet i sshd_config. Detta är ett engångssteg per server; inga ändringar behövs när användare läggs till eller tas bort.
2. När en användare behöver åtkomst skickas deras publika nyckel till CA för signering. CA signerar den med sin privata nyckel och returnerar ett certifikat som innehåller användarens nyckel, deras identitet, de principaler de är auktoriserade som och giltighetsfönstret. Användarens privata nyckel ändras inte.
3. Användaren initierar en anslutning. SSH-klienten presenterar användarens certifikat och bevisar innehav av den privata nyckeln genom att signera autentiseringsbegäran.
4. Servern verifierar CA-signaturen på certifikatet med hjälp av den offentliga CA-nyckel som den redan innehar från steg 1.
5. Servern kontrollerar om certifikattypen är korrekt för användarautentisering.
6. Servern kontrollerar om den aktuella tiden faller inom fönstret "giltigt efter" och "giltigt före".
7. Servern kontrollerar om minst en principal i certifikatet matchar målanvändarkontot.
8. Om alla kontroller godkänns verifierar servern klientens signatur. En giltig signatur bekräftar att klienten innehar motsvarande privata nyckel. Åtkomst beviljas.
9. När giltighetsfönstret stängs slutar certifikatet att fungera automatiskt. Användaren måste få ett nytt certifikat signerat av CA för att få åtkomst igen. Den privata nyckeln lämnar aldrig klienten.

Den strukturella skillnaden från nyckelbaserad autentisering: servern behöver inte en befintlig post för användaren. Förtroendet kommer från CA:n, inte från en fil på varje enskild server.

SSH-nycklar vs SSH-certifikat: En direkt jämförelse

Dimensionera	SSH-nycklar	SSH-certifikat
Förtroendemodell	Varje server litar direkt på individuella publika nycklar som listas i dess authorized_keys-fil.	Varje server är konfigurerad för att lita på en eller flera certifikatutfärdare och accepterar certifikat signerade av dessa certifikatutfärdare.
Format för autentiseringsuppgifter	Fristående offentlig nyckel	Publik nyckel med signerade metadata och CA-signatur
Identitetsinformation	Valfritt kommentarsfält; verifieras inte under autentisering	Signerat nyckel-ID och principer inbäddade i certifikatet och verifierade under autentisering
Utgångsdatum	Ingen inbyggd utgångsdatum; åtkomsten förblir giltig tills nyckeln manuellt tas bort från varje server	Inbyggd giltighetsperiod tillämpas under autentisering; certifikat avvisas automatiskt när fönstret stängs
Åtkomstprovisionering	Publika nycklar måste distribueras till varje server där åtkomst krävs	Servrar litar på certifikatutfärdaren; användare får certifikat utfärdade av certifikatutfärdaren; inga ändringar per server när användare läggs till
Borttagning av åtkomst	Publika nycklar måste tas bort från varje server där de är betrodda; servrar som är lätta att missa	Förnya inte certifikatet; åtkomsten upphör automatiskt. Tidig återkallelse via Key Revocation List (KRL) är möjlig men kräver KRL-distribution till alla servrar.
Rotation	Kräver att ett nytt nyckelpar genereras, den nya publika nyckeln distribueras och den gamla nyckeln tas bort från alla servrar.	Utfärda ett nytt certifikat; det underliggande nyckelparet kan återanvändas om organisationens policy tillåter det
Serveradministration	Kräver att authorized_keys-poster bibehålls på alla servrar för alla användare.	Kräver att CA-förtroendekonfigurationen underhålls en gång per server och att certifikatutfärdandet hanteras
gransking	Loggar visar nyckelfingeravtryck; ägarskapskartläggning kräver externa register; svårt att tillskriva individer när nycklar delas	Certifikat bäddar in signerade identitetsattribut, nyckel-ID:n och serienummer som förbättrar spårbarheten direkt i autentiseringsloggar.
Skalbarhet	Administrationsarbetet växer linjärt med antalet användare, nycklar och servrar.	Ledningsinsatserna skiftar mot centraliserad certifikatutfärdande och CA-styrning; att lägga till användare kräver inga ändringar per server
Infrastrukturkrav	Ingen CA-infrastruktur krävs	Kräver ett CA-nyckelpar, certifikatutfärdandeprocess och distribution av CA-förtroende till alla servrar
Efterlevnadsställning	Kräver aktiv hantering av inventering, rotation och återkallelse för att uppfylla ramverk för åtkomstkontroll	Inbyggda utgångs- och centraliserade utfärdandeloggar producerar naturligt bevis på efterlevnad; kortlivade certifikat minskar efterlevnadsbördan av manuell återkallelse.
Typiskt användningsfall	Små till medelstora miljöer, statiska åtkomstrelationer, enkla implementeringar med aktiv nyckelstyrning	Storskaliga miljöer, dynamisk åtkomsthantering, centraliserad identitetsstyrning eller organisationer där SSH-nyckelinventeringen har överskridit den manuella hanteringskapaciteten.

Livscykelägande: SSH-nycklar kontra SSH-certifikat

Livscykelstadiet	SSH-nycklar: vem är ansvarig	SSH-certifikat: vem är ansvarig
Generation	Användare eller automatiseringssystem; kräver policytillämpning på algoritm och nyckellängd	Användaren skickar in den offentliga nyckeln till CA; CA signerar och returnerar certifikatet; algoritm och giltighet upprätthålls av CA-policy
Distribution	Administratör eller automatiserat verktyg distribuerar offentlig nyckel till varje auktoriserad servers authorized_keys-fil	Användaren får certifikat; servrarna behöver inga ändringar; CA:s publika nyckel har redan distribuerats
Övervakning	Sessionsloggar visar viktiga fingeravtryck; ägarskapskartläggning kräver extern inventering	Certifikatnyckel-ID och serienummer visas i loggar; identitet direkt hänförbar till loggen
Rotation	Nytt nyckelpar genererat; ny publik nyckel distribuerad till alla servrar; gammal nyckel borttagen från alla servrar	Nytt certifikat utfärdat; tidigare certifikat upphör att gälla automatiskt; inga ändringar av authorized_keys per server behövs
Återkallelse vid avresa	Den offentliga nyckeln måste identifieras och tas bort från alla servrar; gapet mellan avgång och slutförande är en efterlevnadsrisk	Stoppa utfärdandet av certifikat till den avlidna användaren; befintligt certifikat upphör att gälla inom giltighetsfönstret; KRL-post för omedelbar förtida återkallelse
Revisionsbevis	Genererad från sessionsloggar + extern nyckelinventering; kräver korrelation	CA-utgivningsloggen tillhandahåller direkt attribution; giltighetsfönstret ger automatiskt bevis på tidsbegränsad åtkomst

Vilken ska du använda: SSH-nycklar eller SSH-certifikat?

Ingen av metoderna är universellt överlägsen. Rätt val beror på miljöns skala, styrningens mognad och operativa kapacitet:

• SSH-nycklar är praktiska och säkra i små till medelstora miljöer där nyckelregistret är känt, ägarna dokumenteras, rotationen verkställs enligt schema och återkallelse sker omedelbart vid avgång. Styrningskraven för SSH-nycklar är hanterbara i denna skala när de stöds av en SSH-nyckelhanteringsplattform.
• SSH-certifikat blir fördelaktiga när: organisationen inte kan producera en aktuell inventering av alla SSH-nycklar på begäran; hanteringen av authorized_keys-filer över hundratals servrar skapar inkonsekvens; tiden från medarbetarens avgång till slutförd SSH-återkallelse är längre än acceptabelt; efterlevnadsrevisioner ger resultat om överblivna eller oroterade nycklar; eller miljön skalar snabbare än manuell nyckelhantering kan spåra.
• Övergången kan vara stegvis: Servrar kan lita på både traditionella publika nycklar och certifikatutfärdaren samtidigt under migreringen. Detta innebär att befintliga nycklar förblir funktionella medan certifikatbaserad autentisering rullas ut, vilket möjliggör en gradvis migrering med låg risk.

För organisationer som övergår till certifikat eller modeller för tillfällig åtkomst, se Transformera statiska SSH-nycklar till kortlivade arbetsbelastningsidentiteter för migreringsramverket och SPIFFE/SPIRE-arbetsbelastningsidentitetsmetoden för tjänstkonton.

Rotations- och återkallningsutlösare

• Anställds avgång eller rollbyte: För SSH-nycklar, ta omedelbart bort den publika nyckeln från alla servrar; för SSH-certifikat, sluta utfärda certifikat och lägg till en KRL-post för omedelbar och förtida återkallelse av alla giltiga certifikat.
• Misstänkt eller bekräftad kompromiss: För SSH-nycklar, återkalla dem på alla servrar och generera en ersättning; för SSH-certifikat, lägg till en KRL-post och utfärda dem på nytt från CA.
• Algoritmutfasning: Alla nycklar eller certifikat som använder föråldrade algoritmer (DSA, RSA-1024) måste ersättas. För algoritmjämförelse, se Jämförelse av SSH-nycklar: RSA, DSA, ECDSA eller EdDSA.
• Avveckling av systemet: ta bort alla SSH-nyckelauktoriseringar för avaktiverade system; för certifikatdistributioner, uppdatera AuthorizedPrincipalsFile på återstående system.
• Kompromettering av CA:s privata nyckel: För certifikatdistributioner är detta den mest kritiska händelsen: CA:s publika nyckel måste ersättas på varje server och alla tidigare utfärdade certifikat blir opålitliga. Skydda CA:s privata nycklar i HSM:er för att förhindra detta scenario.

Incidentrespons: SSH-nyckel kontra SSH-certifikatkompromiss

• Komprometterad SSH-nyckel: identifiera alla servrar med den publika nyckeln i authorized_keys (kräver inventering); ta bort den publika nyckeln från varje server; generera ett nytt nyckelpar; distribuera den nya publika nyckeln till auktoriserade servrar; verifiera att den nya nyckelautentiseringen fungerar; logga alla åtgärder med tidsstämplar för att bevisa efterlevnad.
• Komprometterat SSH-certifikat: lägg till certifikatets serienummer i KRL; distribuera den uppdaterade KRL:en till alla servrar omedelbart; certifikatet avvisas vid nästa anslutningsförsök; utfärda ett nytt certifikat efter att felet med hanteringen av autentiseringsuppgifter har åtgärdats; om den underliggande privata nyckeln har komprometterats, rotera även nyckelparet.
• Komprometterad CA-privat nyckel (certifikatdistributioner): generera ett nytt CA-nyckelpar; distribuera den nya CA-publika nyckeln till alla servrar (ersätter den gamla TrustedUserCAKeys-posten); utfärda certifikat på nytt för alla användare från den nya CA:n; den gamla CA-publika nyckeln kan tas bort från servrar när alla användare har migrerats till den nya CA:n. Detta är den allvarligaste händelsen; skydda CA:s privata nycklar i HSM:er för att förhindra det.

Hur krypteringskonsulting kan hjälpa

På Encryption Consulting förstår vi de utmaningar som företag står inför när de hanterar SSH-nycklar i stor skala. SSH Secure erbjuder heltäckande nyckellivscykelsäkerhet, centraliserad synlighet och HSM-stödt skydd för både SSH-nycklar och certifikatmiljöer:

1. Centraliserad synlighet och ägarkartläggning

Agentbaserad och agentlös identifiering lokaliserar varje SSH-nyckel på olika servrar och användarmaskiner. Alla nycklar lagras i ett enhetligt lager med ägarskaps- och användningsinformation, vilket eliminerar överblivna nycklar och säkerställer fullständig ansvarsskyldighet i hela miljön.

2. Automatiserad nyckellivscykelorkestrering

SSH Secure automatiserar hela nyckellivscykeln: säker generering, policydriven rotation och återkallelse. Tillfälliga sessionsbundna nycklar upphör automatiskt för känsliga operationer, vilket framtvingar åtkomst med lägst behörighet och säkerställer att nycklarna inte sparas längre än sin avsedda användning.

3. HSM-integrerat skydd

Alla privata nycklar genereras och lagras i HSM :er med hjälp av RSA-4096, ECDSA och Ed25519. Icke-exporterbar, manipulationssäker lagring av privata nycklar förhindrar extrahering även vid kompromettering på värd-OS-nivå.

4. Policydriven kontroll för nyckeloperationer

Alla viktiga operationer verkställs genom policybaserade kontroller som säkerställer konsekvens i hela miljön, minskade manuella fel och efterlevnad av myndighetskrav eller interna styrningsmodeller.

5. Kontinuerlig övervakning, revision och efterlevnadsberedskap

Realtidsövervakning med detaljerad händelseloggning, Splunk- eller Grafana Loki-integration, nedladdningsbara granskningsloggar och efterlevnadsrapporter som ger säkerhetsteam tydlig inblick i nyckelanvändning och övergripande status.

Slutsats

SSH-nycklar och SSH-certifikat löser samma autentiseringsproblem på kryptografisk nivå. Båda bevisar identitet utan att överföra ett lösenord. Skillnaden ligger inte i kryptografins styrka; den ligger i vad som händer med åtkomsten över tid. En nyckel som placerades på en server för tre år sedan av någon som inte längre arbetar på organisationen är lika giltig idag som den dag den lades till. Servern har inget sätt att veta något annat. Det är inte en brist i nyckeln; det är en konsekvens av en decentraliserad förtroendemodell utformad för enkelhet.

Gapet finns i styrningen genom hela autentiseringsuppgifternas livscykel. För organisationer där SSH-nycklar är kända, ägarskapet dokumenteras och rotation och återkallelse tillämpas konsekvent, förblir SSH-nycklar ett säkert och praktiskt val. För organisationer där inventeringen har vuxit bortom vad manuell hantering kan spåra, ger SSH-certifikat strukturella fördelar: inbyggt utgångsdatum, centraliserade utfärdandeloggar och eliminering av hantering av authorized_keys per server. Att stärka SSH-nyckelstyrningen genom centraliserad identifiering, ägarskapsmappning, policydriven rotation och snabb återkallelse är det mest omedelbara och praktiska steget mot att säkra privilegierad åtkomst, oavsett om en migrering till certifikat planeras eller inte. För relaterad läsning, se SSH Key Management Compliance , Why Never-Expiring SSH Keys Are a Security Risk och Transform Static SSH Keys into Short-Lived Workload Identities.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan SSH-nycklar och SSH-certifikat?

SSH-nycklar skapar förtroende genom att placera användarens publika nyckel i serverns authorized_keys-fil. Förtroendet har inget utgångsdatum och ingen central post; det kvarstår tills nyckeln manuellt tas bort från varje server. SSH-certifikat använder en betrodd certifikatutfärdare för att verifiera identiteter; servern litar på certifikatutfärdaren, certifikatet har ett inbyggt giltighetsfönster och åtkomsten upphör automatiskt när fönstret stängs.

Vilket ska jag använda: SSH-nycklar eller SSH-certifikat?

SSH-nycklar är praktiska när inventeringen är känd, ägarskapet är dokumenterat och styrningen är aktiv. SSH-certifikat är fördelaktiga när nyckelinventeringen har vuxit bortom manuell spårning, återkallelsen är långsam eller efterlevnadsrevisioner ger resultat. Övergången kan vara stegvis: servrar kan lita på båda modellerna samtidigt under migreringen.

Upphör SSH-certifikat att gälla automatiskt?

Ja. SSH-certifikat har ett giltighetsfönster (tidsstämplar för giltigt efter och giltigt före) som tillämpas under autentisering. När den aktuella tiden faller utanför fönstret avvisas certifikatet oavsett tidigare förtroende. SSH-nycklar har inget inbyggt utgångsdatum; de förblir betrodda tills de manuellt tas bort från authorized_keys på varje server.

Hur återkallar man ett SSH-certifikat innan det går ut?

Via en nyckelåterkallningslista (KRL): CA-administratören lägger till certifikatets serienummer eller nyckelfingeravtryck i KRL:n; varje server kontrollerar KRL:n via direktivet RevokedKeys sshd_config. Begränsning: KRL:n måste distribueras till alla servrar innan återkallelsen träder i kraft. Kortlivade certifikat minskar detta problem: ett certifikat som är giltigt i åtta timmar löper ut innan de flesta återkallningsbehov uppstår.

Vad är driftskostnaden för att driftsätta en SSH CA?

Engångsåtgärd: generera CA-nyckelpar; distribuera CA:s publika nyckel till alla servrar via TrustedUserCAKeys. Skydda CA:s privata nyckel i HSM för miljöer med hög säkerhetsnivå. Pågående: hantera certifikatutfärdande (integrera med identitetsleverantörer, ange principaler och giltighetsperioder); CA-nyckelrotation enligt ett flerårigt schema; KRL-hantering för tidig återkallelse. I gengäld: eliminera hantering av authorized_keys per server för alla användare som omfattas av certifikat.

Är SSH-certifikat samma sak som TLS-certifikat?

Nej. SSH-certifikat använder formatet OpenSSH PROTOCOL.certkeys (SSH-specifikt), inte X.509 (används för TLS/HTTPS). Båda använder en CA som garanterar en offentlig nyckel, men formaten är strukturellt olika och inte utbytbara. En SSH CA är i sig helt enkelt ett SSH-nyckelpar, inte en X.509 CA.