Posredovanje agenta SSH proti kopiranju ključa: kaj v resnici uhaja

Dva različna dogodka imenujemo uhajal ključ SSH, in zahtevata različna odziva. Preverjanje z javnim ključem pošlje javni ključ in podpis, ustvarjen z zasebnim ključem, zato zasebni ključ ni nikoli polje zahteve. Posredovanje agenta izpostavi nekaj drugega, ker lahko oddaljeni gostitelj, ki doseže vašega posredovanega agenta, od njega zahteva podpis, ne da bi ključ kdaj imel. Če oba obravnavate kot en dogodek, končate bodisi z nesmiselno zamenjavo ključa bodisi z delegiranjem, ki ostane aktivno.

Prijava z javnim ključem prenese podpis, ne ključa

Izmenjava preverjanja nosi uporabnikov javni ključ in podpis nad podatki seje. Strežnik ta podpis preveri s ključem, ki mu že zaupa, zato lahko zasebna polovica ostane na odjemalcu tudi prek nezanesljivega omrežja. Upravljavec VPN, ki opazuje tunel, v vsakem primeru vidi šifrirano sejo SSH.

To opisuje protokol, ne zanesljivosti vsake končne točke na poti. Ohranite preverjanje identitete gostitelja nedotaknjeno, ker se je odjemalec, ki sprejme kateri koli gostiteljev ključ, odpovedal drugemu nadzoru od tega, o katerem govorimo. Ujeta seja in ujet ključ sta ločeni ugotovitvi in le ena od njiju je izguba poverilnic. Oba držite v ločenih stavkih poročila.

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

Prvi ukaz natisne javni odtis, da ga primerjate s tistim, ki ga navaja strežnik. Drugi naredi preverjanje gostiteljevega ključa izrecno, namesto da bi se zanašal na privzeto vrednost, ki je nihče ni prebral. Zaženite oba, preden karkoli spremenite pri ključih, da bo izhodišče dokumentirano.

Posredovanje agenta prenese zmožnost podpisovanja

Ko je posredovanje vklopljeno, se na oddaljenem gostitelju pojavi vtičnica in lokalni agent odgovarja na zahteve, ki prihajajo skoznjo. Kdor koli lahko to vtičnico med sejo uporablja, se lahko pred gostitelji, ki sprejmejo naložene identitete, predstavi kot vi. Noben zasebni ključ za to ne prečka omrežja.

Izpostavljena je zmožnost, ne datoteka. Zato posredovanje pripada imenovani nalogi in imenovanemu gostitelju, ne vsaki povezavi, ki jo sklene prenosnik. Preskočni gostitelj, ki povezavo posreduje brez posredovanega agenta, običajno potrebo povsem odpravi.

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

Prvi našteje, katere identitete ima agent zdaj, kar je vredno vedeti, preden njegovo vtičnico izročite drugemu stroju. Drugi se poveže brez delegiranja. Tretji pokaže vzorec preskočnega gostitelja, ki pogosto povsem nadomesti posredovanje.

Izberite odziv glede na dokaze, ki jih imate

Identiteta za podpisovanje, za katero se domneva, da je izpostavljena, zahteva postopek zamenjave in preklica ter odstranitev njenega sprejemanja iz storitev, ki so ji zaupale. Brisanje kopije na prenosniku pusti vse druge kopije nedotaknjene. Začnite s storitvami, nato počistite odjemalce.

Začasna težava z delegiranjem je ožja. Končajte posredovanje, ki ni bilo potrebno, in z lastnikom incidenta pregledajte, katere seje in identitete je pokrivalo. Zamenjava ključa lahko sledi, vendar o tem odločajo dokazi, ne skrb.

Odsotnost opaženega izvoza dokazuje le, da se mehanizem, ki ste se ga bali, ni pojavil. Ne pove ničesar o tem, kaj bi še lahko storil gostitelj na drugem koncu te vtičnice.

Nadzore v poročilu držite ločeno

Zaščitite zasebno gradivo, omejite, kdo lahko od njega zahteva podpis, ohranite preverjeno identiteto druge strani. To so trije nadzori, ki se medsebojno krepijo, in noben ne nadomesti drugega, ko pojasnjujete, kaj se je zgodilo.

Kompromitiran prenosnik ali privilegirana aplikacija na njem je tretji primer z veliko širšim dosegom. Sprememba poti VPN tega ne reši in ne obnovi zaupanja v ključ, ki je bil morda prebran z diska.

Zapišite, kateri komponenti se je zaupalo, ali je bilo posredovanje vklopljeno in kaj je bilo v resnici opaženo. Prav ta zapis naredi naslednjo odločitev zagovorljivo, namesto ugibanja o tem, kaj pomeni uhajanje.