Prosljeđivanje SSH agenta naspram kopiranja ključa: šta zapravo curi

Dva različita događaja nazivaju se procurio SSH ključ, i traže različite reakcije. Autentifikacija javnim ključem šalje javni ključ i potpis napravljen privatnim ključem, pa privatni ključ nikada nije polje u zahtjevu. Prosljeđivanje agenta izlaže nešto drugo, jer udaljeni host koji može doći do vašeg proslijeđenog agenta može ga zamoliti da potpiše, a da pritom nikada ne drži ključ. Ako to tretirate kao jedan događaj, završavate ili s besmislenom zamjenom ključa ili s delegiranjem koje ostaje aktivno.

Prijava javnim ključem prenosi potpis, a 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 nepouzdane mreže. Operater VPN-a koji gleda tunel u svakom slučaju vidi šifrovanu SSH sesiju.

To opisuje protokol, a ne pouzdanost svake krajnje tačke na putu. Očuvajte provjeru identiteta hosta, jer klijent koji prihvata bilo koji ključ hosta odrekao se druge kontrole od one o kojoj govorimo. Presretnuta sesija i presretnut ključ su odvojeni nalazi, a samo jedan od njih je 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 komanda ispisuje javni otisak da ga uporedite s onim što server navodi. Druga čini provjeru ključa hosta eksplicitnom umjesto oslanjanja na podrazumijevanu vrijednost koju niko nije pročitao. Pokrenite obje prije nego što promijenite bilo šta u vezi s ključevima, da osnovica bude dokumentovana.

Prosljeđivanje agenta delegira mogućnost potpisivanja

Kad je prosljeđivanje uključeno, na udaljenom hostu se pojavljuje utičnica, a lokalni agent odgovara na zahtjeve koji kroz nju pristižu. Svako ko može koristiti tu utičnicu tokom sesije može se predstaviti kao vi prema hostovima koji prihvataju 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 laptop ostvari. Skakački 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 drugoj mašini. Druga se povezuje bez delegiranja. Treća pokazuje obrazac skakačkog hosta koji često u potpunosti 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 njegovog prihvatanja iz servisa koji su mu vjerovali. Brisanje kopije na laptopu ostavlja svaku drugu kopiju netaknutom. Počnite od servisa, pa očistite klijente.

Privremeni problem s delegiranjem je uži. 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 šta je još host s druge strane te utičnice mogao učiniti.

Držite kontrole odvojenim u izvještaju

Zaštitite privatni materijal, ograničite ko 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 šta se dogodilo.

Kompromitovan laptop ili privilegovana 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, da li je prosljeđivanje bilo uključeno i šta je zaista uočeno. Upravo taj zapis čini sljedeću odluku odbranjivom, umjesto nagađanja o tome šta curenje znači.