SSH – Nyckelhantering och bästa praxis

Secure Shell (SSH) är ett nätverksprotokoll som använder kryptografi med offentliga nycklar för att autentisera användare och kryptera data som flödar till och från fjärrsystem. SSH är den primära mekanismen för fjärrserveradministration, filöverföringar mellan system och automatiserad åtkomst i CI/CD-pipelines. Eftersom SSH-nycklar inte har någon inbyggd utgångsdatum, ingen certifikatutfärdare och ingen återkallningsmekanism, ackumuleras de tyst i authorized_keys-filer över infrastrukturen, vilket skapar beständiga åtkomstvägar som sällan granskas. Den rekommenderade åtgärden: kör en identifieringsskanning för att inventera alla SSH-nycklar i din miljö, implementera en nyckelrotationspolicy med en maximal nyckelålder på högst ett till två år, inaktivera lösenordsautentisering på alla SSH-servrar, tillämpa rollbaserade åtkomstkontroller för nyckelhantering och eliminera hårdkodade nycklar från applikationskoden.

Snabbt svar: Vad är SSH-nyckelhantering och varför är det viktigt?

SSH-nyckelhantering är processen att upptäcka, inventera, kontrollera, rotera och granska SSH-nyckelpar i en organisations infrastruktur. Det är viktigt eftersom SSH-nycklar är kraftfulla autentiseringsuppgifter utan inbyggd utgångs- eller återkallningsmekanism: en authorized_keys-post ger åtkomst till alla som innehar motsvarande privata nyckel, på obestämd tid, såvida inte nyckeln uttryckligen roteras eller tas bort. Stora organisationer samlar på sig hundratusentals authorized_keys-poster, många kopplade till tidigare anställda, entreprenörer eller servicekonton som borde ha återkallats flera år tidigare. Dålig SSH-nyckelhantering skapar ihållande bakdörrar, möjliggör lateral förflyttning mellan servrar och bryter mot efterlevnadskraven enligt PCI DSS, NIST SP 800-53 och HIPAA.

Vad är SSH och hur fungerar det?

SSH (Secure Shell), definierat i RFC 4251-4254, är ett kryptografiskt nätverksprotokoll för säker fjärråtkomst, filöverföring och tunnling. Det fungerar enligt principen om kryptografi med publik nyckel, med hjälp av nyckelpar där den publika nyckeln placeras på servrar i filen authorized_keys och den privata nyckeln innehas av användaren eller systemet som begär åtkomst. När en SSH-klient ansluter till en server, utmanar servern klienten att bevisa att den innehar den privata nyckeln som motsvarar en auktoriserad publik nyckel, utan att den privata nyckeln någonsin överförs över nätverket.

Typiska SSH-användningsfall inkluderar fjärrinloggning till servrar och nätverksenheter, filöverföringar mellan system (SCP, SFTP), automatiserad CI/CD-pipelineåtkomst till bygg- och driftsättningsservrar, portvidarebefordran och tunnling samt programmatisk API-åtkomst där SSH används som transport.

SSH-nycklar kontra X.509-certifikat: Viktiga skillnader

Fast egendom	SSH-nycklar	X.509-certifikat (TLS)
Styrande myndighet	Inga; nycklarna är självstyrande inom organisationen	Certifikatutfärdare (CA) utfärdar och signerar certifikat; CA/Browser Forum styr offentliga CA:er
Inbyggd utgångsdatum	Ingen utgångsdatum; authorized_keys-poster sparas på obestämd tid om de inte tas bort manuellt	Certifikat har giltighetsdatum för NotBefore och NotAfter som framtvingas av klienter
Återkallelsemekanism	Ingen motsvarighet till CRL eller OCSP; återkallelse kräver att den publika nyckeln tas bort från authorized_keys på varje server.	CRL (Certificate Revocation List) och OCSP (Online Certificate Status Protocol) möjliggör återkallelse
Identitetsvalidering	Ingen CA-validering; servern litar på vilken nyckel som helst i authorized_keys oavsett vem som genererade den.	CA validerar certifikatinnehavarens identitet före utfärdande (för publika CA:er: domänvalidering eller organisationsvalidering)
Möjlighet för fjärråtkomst	Möjliggör fjärrinloggning och kommandokörning på servrar	Tillhandahåller autentisering för nätverksanslutningar men aktiverar inte fjärråtkomst via skalet på egen hand
Lagerutmaning	Inget centralt register; nycklar måste upptäckas genom att skanna servrar och system	Certifikat kan upptäckas via loggar för certifikattransparens; PKI-verktyg spårar utfärdade certifikat

Risker med ohanterade SSH-nycklar

Avsaknaden av inbyggda funktioner för utgångsdatum och återkallelse gör SSH-nyckelstyrning till en tydlig utmaning jämfört med certifikathantering. Specifika risker som ohanterade SSH-nycklar skapar:

• Ihållande bakdörrar från tidigare anställda och entreprenörer: När en utvecklare, systemadministratör eller entreprenör slutar, finns deras publika SSH-nyckel kvar i authorized_keys-filer på varje server de hade åtkomst till, såvida den inte uttryckligen tas bort. En tidigare anställd som fortfarande innehar sin privata nyckel behåller åtkomst till dessa servrar på obestämd tid.
• Nyckelutbredning som möjliggör lateral rörelse: I stora organisationer kan ett enda tjänstkonto eller byggsystem ha sin publika nyckel i authorized_keys på hundratals servrar. En angripare som komprometterar ett system med en auktoriserad privat SSH-nyckel kan använda den nyckeln för att autentisera mot alla andra servrar som litar på motsvarande publika nyckel, vilket möjliggör snabb lateral förflyttning över miljön.
• Föråldrade nycklar med svaga algoritmer: Nycklar som genererades för flera år sedan kan använda RSA-1024 eller DSA (båda föråldrade) eftersom policyn och verktygen vid den tiden inte tillämpade starkare algoritmer. Utan en identifierings- och inventeringsprocess finns dessa svaga nycklar kvar i authorized_keys på obestämd tid.
• Hårdkodade nycklar i applikationer: SSH-nycklar som är inbäddade i programkod, Docker-avbildningar eller konfigurationsfiler är svåra att rotera, kan exponeras via källkodsdatabaser och finns kvar i versionshistoriken även efter att de har tagits bort från den aktuella kodbasen.
• Tangentrotation hoppas ofta över: Utan automatiserad hantering kräver nyckelrotation att authorized_keys uppdateras manuellt på varje server som litar på nyckeln. I miljöer med hundratals servrar är detta operativt betungande och skjuts ofta upp på obestämd tid.

Algoritm och val av nyckeltyp för SSH

Nyckeltyp	Algoritm	Säkerhetsstyrka	Rekommendation	Anmärkningar
Ed25519	Edwards-kurva DSA (EdDSA)	128-bitars	Föredras för ny SSH-nyckelgenerering	Snabb, kompakt (32-byte publik nyckel), motståndskraftig mot tidsbaserade sidkanalattacker, stöds av OpenSSH 6.5+ (släppt 2014)
ECDSA P-256	Elliptisk kurva DSA	128-bitars	Godtagbart; använd Ed25519 istället om tillgängligt	Bredare kompatibilitet med äldre system; mindre motståndskraftig mot tidsattacker än Ed25519
RSA-3072	RSA	128-bitars	Acceptabelt där Ed25519/ECDSA inte stöds	Mycket större nyckelstorlek (384 byte jämfört med 32 byte för Ed25519); långsammare drift; kompatibel med det bredaste utbudet av äldre system
RSA-2048	RSA	112-bitars	Minimum; planera migrering till starkare nyckeltyper	Föreslagen för utfasning efter 2030 enligt NIST IR 8547; använd RSA-3072 eller Ed25519 för nya nycklar
RSA-1024	RSA	80-bitars (trasig)	Använd inte	NIST tillåts inte för nya nycklar; beräkningsmässigt förstörbar
DSA	DSA (original)	80-bitars (föråldrad)	Använd inte	Åtgärdade nyckelstorleken på 1024 bitar; formellt föråldrad av NIST; borttagen från OpenSSH 7.0+ som standard

Bästa praxis för SSH-nyckelhantering

1. Få fullständig insyn genom upptäckt: Det första steget i SSH-nyckelhantering är att veta vad du har. Kör regelbundna identifieringsskanningar över alla servrar och nätverksenheter för att lokalisera och inventera alla authorized_keys-poster och alla privata SSH-nycklar i nätverket. Mappa varje auktoriserad offentlig nyckel till den användare eller det systemkonto som äger den, de servrar den ger åtkomst till, när den genererades och vilken algoritm och nyckelstorlek den använder. Utan denna inventering är ingen annan styrningskontroll meningsfull.
2. Tillämpa en maximal nyckelålder och rotationspolicy: Definiera en policy som kräver att SSH-nycklar roteras enligt ett definierat schema. För interaktiva användarnycklar är en maximal ålder på ett till två år vanlig. För servicekonton och automatiserade system är kortare rotationsintervall lämpliga för åtkomst med högre risk. Rotation kräver att ett nytt nyckelpar genereras, den nya publika nyckeln distribueras till alla auktoriserade servrar, åtkomst verifieras och den gamla publika nyckeln tas bort från alla authorized_keys-filer. Automatisera denna process i stora miljöer.
3. Inaktivera lösenordsautentisering på SSH-servrar: Konfigurera alla SSH-servrar med PasswordAuthentication no och ChallengeResponseAuthentication no i sshd_config. Kräv endast nyckelbaserad autentisering. Lösenordsautentisering är sårbar för brute-force-attacker och nätfiske; SSH-nyckelautentisering är immun mot båda när den hanteras korrekt.
4. Tillämpa revisionsspår och policy: Logga alla SSH-autentiseringshändelser, inklusive vilken nyckel som användes och från vilken källans IP, till en centraliserad SIEM. Dessa loggar är viktiga för att upptäcka obehörig åtkomst (till exempel en gammal nyckel som används från en oväntad plats efter att en tidigare anställd har slutat) och för att visa efterlevnad av PCI DSS-, NIST SP 800-53- och HIPAA-revisionskrav. Anpassa loggkonfigurationen till din organisations policy för nyckelanvändning.
5. Implementera rollbaserade behörigheter för nyckelhantering: begränsa vem som kan lägga till, ändra eller ta bort poster i authorized_keys-filer. I miljöer där administratörer godtyckligt kan lägga till authorized_keys-poster utan tillsyn ackumuleras obehöriga eller odokumenterade åtkomsttillstånd. Använd katalogtjänster eller en centraliserad SSH-nyckelhanteringsplattform för att säkerställa att alla nyckeltilldelningar följer ett godkännandearbetsflöde och registreras i inventeringen.
6. Eliminera hårdkodade nycklar från programkoden: Privata SSH-nycklar som är inbäddade i applikationskod, containeravbildningar eller konfigurationsfiler är farliga: de är svåra att rotera, kan exponeras via källkodsdatabaser (inklusive databasens historik efter borttagning) och har ofta bred åtkomst. Ersätt hårdkodade nycklar med dynamiskt provisionerade autentiseringsuppgifter som hämtas från ett hemlighetshanteringssystem vid körning.
7. Använd lösenfrasskyddade privata nycklar för interaktiv användning: Privata SSH-nycklar som används för interaktiv inloggning bör skyddas med ett starkt lösenfras. Lösenfrasen krypterar den privata nyckelfilen så att en angripare som får tag på nyckelfilen inte kan använda den utan att känna till lösenfrasen. För automatiserade system bör den privata nyckeln lagras i ett hemlighetshanteringssystem med åtkomstkontroller snarare än i klartext i filsystemet.

Implementeringsexempel: SSH-nyckelstyrning för företag

En organisation med 500 Linux-servrar och en DevOps-miljö som använder SSH för CI/CD-pipelineåtkomst implementerar följande SSH-nyckelstyrningsprogram:

1. Första upptäckten: Kör en SSH-nyckelidentifieringssökning på alla 500 servrar. Skanningen räknar upp alla poster i /root/.ssh/authorized_keys och /home/*/.ssh/authorized_keys, och katalogiserar varje offentlig nyckels fingeravtryck, algoritm, nyckelstorlek och de konton och servrar den visas på. Den första skanningen avslöjar 47 000 authorized_keys-poster, varav 12 000 inte har något motsvarande användarkonto i den aktuella Active Directory, vilket indikerar tidigare anställdas eller entreprenörsnycklar som aldrig återkallades.
2. Akut återkallelse av överblivna nycklar: De 12 000 överblivna authorized_keys-posterna tas bort från alla berörda servrar. De 35 000 återstående posterna tilldelas nuvarande användar- eller tjänstkonton och läggs till i nyckelregistret med granskningsstatusen väntar.
3. Algoritmsanering: Inventeringen identifierar 3 200 RSA-1024-nycklar och 800 DSA-nycklar som måste bytas ut. Nya Ed25519-nycklar genereras för de berörda användarna och tjänstkontona, distribueras till alla relevanta servrar, och de gamla nycklarna tas bort. RSA-2048-nycklar flaggas för rotation till RSA-3072 eller Ed25519 vid nästa schemalagda rotation.
4. Implementering av rotationsschema: En policy upprättas som kräver att alla SSH-nycklar roteras årligen för interaktiva användare och var sjätte månad för tjänstekonton med åtkomst till produktionssystem. En SSH-nyckelhanteringsplattform automatiserar rotationen: generering av nya nycklar, uppdatering av authorized_keys på berörda servrar och borttagning av gamla nycklar efter bekräftad lyckad autentisering med den nya nyckeln.
5. Ersättning av CI/CD-pipeline-autentiseringsuppgifter: Privata SSH-nycklar som är hårdkodade i CI/CD-pipelinekonfigurationsfiler identifieras och ersätts med dynamiskt provisionerade kortlivade autentiseringsuppgifter som hämtas från ett hemlighetshanteringssystem vid byggtillfället. De gamla hårdkodade nycklarna återkallas och tas bort från authorized_keys.
6. Löpande revisionsloggning: SSH-autentiseringshändelser vidarebefordras till SIEM. Aviseringar konfigureras för autentiseringshändelser med nycklar som är äldre än policyns maximala ålder, autentisering från oväntade käll-IP-adresser med tjänstkontonycklar och alla nya authorized_keys-poster som läggs till utanför det godkända arbetsflödet.

Begränsningar för SSH-nyckelhanteringskontroller

• Ingen inhemsk central myndighet: SSH saknar en CA-modell, så det finns ingen enskild sanningskälla för vilka nycklar som finns. Varje authorized_keys-fil på varje server är en oberoende förtroendekälla. Att upprätthålla en konsekvent inventering kräver aktiv identifieringsskanning snarare än att fråga ett centralt register.
• Manuell hantering av authorized_keys i stor skala är opraktisk: Organisationer med fler än några dussin servrar kan inte hantera SSH-nyckelstyrning manuellt. Automatiserade SSH-nyckelhanteringsplattformar är ett praktiskt krav, inte en optimering, för företagsmiljöer.
• SSH-certifikatutfärdare (SSH CA:er) som en alternativ modell: OpenSSH stöder ett alternativ till authorized_keys med hjälp av SSH-certifikatutfärdare: SSH-certifikatutfärdaren signerar en användares publika nyckel för att skapa ett SSH-certifikat med inbyggt utgångsdatum och valfri återkallelse. Denna modell tillhandahåller de utgångs- och återkallningsfunktioner som vanliga SSH-nycklar saknar, men kräver att alla SSH-servrar uppdateras för att lita på SSH-certifikatutfärdaren och att arbetsflödet för certifikatutfärdande distribueras. För organisationer som är villiga att investera i infrastrukturen, hanterar SSH-certifikatutfärdare de flesta styrningsutmaningarna med vanliga SSH-nycklar.
• Sårbarhet i kvantberäkning: RSA SSH-nycklar är kvantsårbara. Ed25519- och ECDSA-nycklar är också kvantsårbara men har ett längre förväntat säkert fönster. NIST arbetar med postkvantalgoritmer för asymmetrisk kryptografi; organisationer med SSH-infrastruktur som måste förbli säker in på 2030-talet bör planera för algoritmmigrering i takt med att PQC-standarder mognar.

Hur krypteringskonsulting kan hjälpa

• SSH-säker: vår SSH-säker Lösningen tillhandahåller automatiserad hantering av SSH-nycklars livscykel, inklusive identifieringsskanning, centraliserad inventering, rotationsautomation, policytillämpning och revisionsloggning. Den eliminerar den manuella bördan av SSH-nycklarstyrning i stor skala och säkerställer efterlevnad av PCI DSS-, NIST SP 800-53- och HIPAA-krav för hantering av autentiseringsuppgifter.
• Krypteringsrådgivningstjänster: vår Krypteringsrådgivningstjänster utvärdera din nuvarande SSH-nyckelinfrastruktur, identifiera överblivna nycklar, svaga algoritmer, hårdkodade inloggningsuppgifter och policyluckor och tillhandahålla en åtgärdsplan anpassad till efterlevnadskrav.
• CBOM-säker: CBOM-säkerhet upptäcker alla kryptografiska tillgångar i din miljö, inklusive SSH-nycklar, och tillhandahåller den inventering som behövs för att identifiera svaga algoritmer (RSA-1024, DSA) och planera migrering till starkare nyckeltyper.

Slutsats

SSH-nycklar är kraftfulla autentiseringsuppgifter som ger direkt serveråtkomst. Utan inbyggd utgångsdatum, återkallelsedatum eller en central auktoritet ackumuleras de tyst i authorized_keys-filer och skapar beständiga åtkomstvägar långt efter att den avsedda användningen har upphört. Konsekvenserna av dålig SSH-nyckelhantering sträcker sig från efterlevnadsöverträdelser till betydande dataintrång som möjliggörs av lateral förflyttning genom ett nätverk av servrar som alla litar på samma komprometterade privata nyckel.

Styrningsprogrammet är enkelt: upptäck, inventera, åtgärda svaga algoritmer, framtvinga rotation, inaktivera lösenordsautentisering, begränsa vem som kan hantera nycklar och granska åtkomst kontinuerligt. Automatisering är inte valfritt på företagsnivå: den manuella insatsen att underhålla authorized_keys över hundratals servrar utan verktyg garanterar praktiskt taget att styrningen bryts samman. Om du vill bedöma din SSH-nyckelstatus eller implementera automatiserad livscykelhantering, kontakta Encryption Consulting . För relaterad läsning, se vår guide om nyckelhantering inom kryptografi .

Vanliga frågor om partihandel med mat och dryck

Vad är SSH och hur skiljer det sig från TLS-certifikat?

SSH använder kryptografi med publika nycklar för att autentisera användare och kryptera fjärråtkomstsessioner. SSH-nycklar är självstyrande utan certifikatutfärdare, utan inbyggd utgångsdatum eller någon återkallningsmekanism. TLS-certifikat utfärdas av certifikatutfärdare, har giltighetsdatum och kan återkallas via CRL eller OCSP. SSH möjliggör unikt fjärråtkomst till skalet och kommandokörning, vilket TLS-certifikat ensamma inte kan tillhandahålla.

Vad är SSH-nyckelspridning och varför är det en säkerhetsrisk?

SSH-nyckelspridning är den okontrollerade ackumuleringen av SSH-nyckelpar över infrastruktur utan inventering eller livscykelhantering. Varje authorized_keys-post är en beständig åtkomstväg som förblir aktiv tills den uttryckligen tas bort. Tidigare anställdas och entreprenörers nycklar som aldrig återkallades, och servicekontonycklar distribuerade över hundratals servrar, skapar bakdörrar som angripare kan utnyttja på obestämd tid.

Vilka algoritmer bör användas för SSH-nycklar?

Ed25519 är den för närvarande föredragna algoritmen: 128-bitars säkerhet, snabb, kompakt och motståndskraftig mot timing-sidokanalattacker. ECDSA P-256 är också acceptabelt. RSA-3072 är acceptabelt för äldre kompatibilitet; RSA-2048 är minimum. RSA-1024 och DSA får inte användas. Planera migrering till PQC-algoritmer allt eftersom NIST-standarder för SSH-nyckeltyper mognar.

Hur ska SSH-nycklar roteras?

Generera ett nytt nyckelpar, lägg till den nya publika nyckeln till authorized_keys på alla målservrar, verifiera åtkomst och ta sedan bort den gamla publika nyckeln från alla authorized_keys-filer och förstör den gamla privata nyckeln. Definiera en policy för maximal ålder för nyckeln (ett till två år för interaktiva nycklar; kortare för servicekonton) och automatisera rotation i miljöer med fler än några dussin servrar.

Vilka regelverk kräver SSH-nyckelhanteringskontroller?

PCI DSS-kraven 8.2 och 8.6 behandlar autentiseringsuppgifter och hantering av icke-interaktiva konton, inklusive SSH-nycklar. NIST SP 800-53 AC-2 och IA-5 kräver inventering, rotation och återkallelse av autentiseringsuppgifter. HIPAA Technical Safeguards (164.312(d)) kräver kontroller för enhetsautentisering för system som hanterar ePHI. ISO 27001 Annex A.9.3 och A.9.4 kräver kontroller över kryptografiska autentiseringsmekanismer.

Vad är skillnaden mellan SSH-nycklar och lösenordsautentisering?

SSH-nyckelautentisering använder ett kryptografiskt utmaningssvar; ingen hemlighet överförs över nätverket. Lösenordsautentisering överför ett lösenord (inom den krypterade SSH-sessionen). SSH-nycklar är immuna mot brute-force- och phishing-attacker, använder 256-4096-bitars hemligheter (jämfört med typiska lösenord som kan komma ihåg) och bör vara den exklusiva autentiseringsmetoden på SSH-servrar (PasswordAuthentication-nummer i sshd_config).