Videresending av SSH-agent eller kopi av nøkkel: hva som virkelig lekker

To ulike hendelser omtales som en lekket SSH-nøkkel, og de krever forskjellige tiltak. Autentisering med offentlig nøkkel sender en offentlig nøkkel og en signatur som er laget med den private nøkkelen, så den private nøkkelen er aldri et felt i forespørselen. Videresending av agent eksponerer noe annet, siden en ekstern vert som kan nå den videresendte agenten din, kan be den signere uten å holde nøkkelen i det hele tatt. Ser man de to som én hendelse, sitter man igjen med enten en formålsløs nøkkelrotasjon eller en delegasjon som fortsatt står åpen.

Pålogging med offentlig nøkkel overfører en signatur, ikke nøkkelen

Autentiseringsutvekslingen inneholder brukerens offentlige nøkkel og en signatur over sesjonsdata. Tjeneren verifiserer signaturen med nøkkelen den allerede har tillit til, og derfor kan den private delen bli liggende på klienten selv over et nettverk uten tillit. En VPN-operatør som overvåker tunnelen, ser uansett en kryptert SSH-økt.

Dette beskriver protokollen, ikke hvor pålitelig hvert endepunkt underveis er. Behold vertsidentitetskontrollen uendret, for en klient som godtar hvilken som helst vertsnøkkel, har gitt avkall på en annen kontroll enn den vi drøfter her. En avlyttet økt og en avlyttet nøkkel er to forskjellige funn, og bare det ene er tap av innloggingsdata. Hold dem i hver sin setning også i rapporten.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

Den første kommandoen skriver ut den offentlige fingeravtrykket slik at du kan sammenligne med det tjeneren oppgir. Den andre gjør vertsnøkkelkontrollen eksplisitt i stedet for å forutsette en standardverdi som ingen har lest. Kjør begge før du endrer noe som helst med nøkler, slik at utgangspunktet er dokumentert.

Videresending av agent overlater signeringsretten til en annen

Med videresending påslått dukker det opp en socket på den eksterne verten, og den lokale agenten besvarer forespørsler som kommer inn gjennom den. Den som kan bruke socketen i løpet av økten, kan autentisere seg som deg mot verter som godtar identitetene som er lastet inn. Ingen privat nøkkel går over nettverket for at dette skal fungere.

Det er evnen, ikke filen, som utgjør eksponeringen. Derfor hører videresending hjemme hos en navngitt oppgave og en navngitt vert, ikke hos hver tilkobling en laptop foretar. En sprongvert som formidler tilkoblingen uten en videresendt agent, fjerner som regel behovet fullstendig.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

Den første lister opp hvilke identiteter agenten holder nå, nyttig å vite før du overlater socketen til en annen maskin. Den andre kobler til uten delegering. Den tredje viser mønsteret med sprongvert som ofte erstatter videresending helt og holdent.

La bevisene styre hvilket tiltak du velger

En signeringsidentitet som antas å være eksponert, krever utskifting og tilbakekalling, og at aksepten fjernes fra tjenestene som hadde tillit til den. Sletter du kopien på laptopen, står alle andre kopier urørt. Start med tjenestene og rydd opp i klientene etterpå.

Et forbigående delegeringsproblem er smalere. Avslutt videresendingen som ikke var nødvendig, og gå gjennom med eieren av hendelsen hvilke økter og identiteter den omfattet. Nøkkelutskifting kan komme i etterkant, men det avgjøres av bevis og ikke av bekymring.

At ingen eksport er observert, beviser bare at mekanismen du fryktet, ikke dukket opp. Det sier ingenting om hva en vert i andre enden av den socketen ellers kunne ha gjort.

Hold kontrollene fra hverandre i rapporten

Vern det private materialet, begrens hvem som kan be det om å signere, og hold motpartens identitet bekreftet. Dette er tre kontroller som forsterker hverandre, og ingen av dem trer i stedet for en annen når du forklarer hva som skjedde.

En kompromittert laptop eller et privilegert program på den er et tredje tilfelle med langt større rekkevidde. Å endre VPN-ruten løser ikke dette, og det gjenoppretter ikke tilliten til en nøkkel som kan ha blitt lest fra disken.

Noter hvilken komponent som ble betrodd, om videresending var på, og hva som faktisk ble observert. Det er den protokollen som gjør neste beslutning forsvarlig, framfor en gjetning om hva en lekkasje innebærer.