Prosljeđivanje SSH agenta umjesto kopiranja ključa: što zapravo curi

Dva različita događaja nazivaju se procurili SSH ključ, i zahtijevaju različite odgovore. Autentifikacija javnim ključem šalje javni ključ i potpis načinjen privatnim ključem, pa privatni ključ nikad nije polje u zahtjevu. Prosljeđivanje agenta izlaže nešto drugo, jer udaljeni host koji dosegne vaš proslijeđeni agent može ga zamoliti da potpiše, a da pritom nikad ne drži ključ. Tretirate li to kao jedan događaj, završavate ili s besmislenom zamjenom ključa ili s delegiranjem koje ostaje u pogonu.

Prijava javnim ključem prenosi potpis, ne ključ

Razmjena autentifikacije nosi korisnikov javni ključ i potpis nad podacima sesije. Server provjerava taj potpis prema ključu kojem već vjeruje, zato privatna polovina može ostati na klijentu preko mreže kojoj se ne vjeruje. Operator VPN-a koji promatra tunel u svakom slučaju vidi šifriranu SSH sesiju.

To opisuje protokol, a ne pouzdanost svake krajnje točke na putu. Očuvajte provjeru identiteta hosta netaknutom, jer klijent koji prihvaća bilo koji ključ hosta odrekao se druge kontrole od one o kojoj govorimo. Presretnuta sesija i presretnut ključ odvojeni su nalazi, i samo je jedan od njih gubitak akreditiva. Držite ih u odvojenim rečenicama izvještaja.

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

Prva naredba ispisuje javni otisak kako biste ga usporedili s onim što server navodi. Druga čini provjeru ključa hosta izričitom umjesto oslanjanja na zadanu vrijednost koju nitko nije pročitao. Pokrenite obje prije nego što promijenite bilo što oko ključeva, da osnovica bude dokumentirana.

Prosljeđivanje agenta delegira mogućnost potpisivanja

Kad je prosljeđivanje uključeno, na udaljenom hostu pojavljuje se utičnica, a lokalni agent odgovara na zahtjeve koji kroz nju dolaze. Svatko tko može koristiti tu utičnicu tijekom sesije može se predstaviti kao vi prema hostovima koji prihvaćaju učitane identitete. Nijedan privatni ključ ne prelazi mrežu da bi to radilo.

Sposobnost je izloženost, a ne datoteka. Zato prosljeđivanje pripada imenovanom zadatku i imenovanom hostu, a ne svakoj vezi koju prijenosnik uspostavi. Skočni host koji prenosi vezu bez proslijeđenog agenta obično potpuno uklanja potrebu.

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

Prva navodi koje identitete agent trenutno drži, što je vrijedno znati prije nego što njegovu utičnicu predate drugom stroju. Druga se povezuje bez delegiranja. Treća pokazuje obrazac skočnog hosta koji često u cijelosti zamjenjuje prosljeđivanje.

Odaberite reakciju prema dokazima koje imate

Identitet za potpisivanje za koji se vjeruje da je izložen traži postupak zamjene i opoziva, te uklanjanje njegova prihvaćanja iz servisa koji su mu vjerovali. Brisanje kopije na prijenosniku ostavlja svaku drugu kopiju netaknutom. Počnite od servisa, pa očistite klijente.

Privremeni problem s delegiranjem uži je. Zaustavite prosljeđivanje koje nije bilo potrebno i s vlasnikom incidenta pregledajte koje je sesije i identitete pokrivalo. Zamjena ključa može uslijediti, ali o tome odlučuju dokazi, a ne briga.

Nema uočenog izvoza dokazuje samo da se mehanizam kojeg ste se bojali nije pojavio. To ne govori ništa o tome što je još host s druge strane te utičnice mogao učiniti.

Držite kontrole odvojenima u izvještaju

Zaštitite privatni materijal, ograničite tko može tražiti od njega potpis, zadržite provjereni identitet druge strane. To su tri kontrole koje se međusobno jačaju, i nijedna od njih ne zamjenjuje drugu kada objašnjavate što se dogodilo.

Kompromitiran prijenosnik ili privilegirana aplikacija na njemu treći je slučaj s mnogo širim radijusom djelovanja. Promjena VPN rute to ne rješava i ne vraća povjerenje u ključ koji je možda pročitan s diska.

Zapišite koja je komponenta bila pouzdana, je li prosljeđivanje bilo uključeno i što je zaista uočeno. Upravo taj zapis čini sljedeću odluku obranjivom, umjesto nagađanja o tome što curenje znači.