Dvě různé události se nazývají uniklý SSH klíč a vyžadují různé reakce. Autentizace veřejným klíčem posílá veřejný klíč a podpis vytvořený soukromým klíčem, takže soukromý klíč není nikdy pole požadavku. Přesměrování agenta vystavuje něco jiného, protože vzdálený hostitel, který dosáhne na vašeho přesměrovaného agenta, ho může požádat o podpis, aniž by klíč kdy držel. Když obojí berete jako jednu událost, skončíte buď u zbytečné výměny klíče, nebo u delegování, které zůstane běžet.

Přihlášení veřejným klíčem přenáší podpis, nikoli klíč

Autentizační výměna nese uživatelův veřejný klíč a podpis nad daty relace. Server ověřuje tento podpis proti klíči, kterému už věří, a proto soukromá polovina může zůstat na klientu přes nedůvěryhodnou síť. Operátor VPN, který sleduje tunel, v každém případě vidí šifrovanou relaci SSH.

To popisuje protokol, ne důvěryhodnost každého koncového bodu na cestě. Zachovejte ověřování identity hostitele nedotčené, protože klient, který přijímá jakýkoli klíč hostitele, opustil jinou kontrolu, než o které mluvíme. Zachycená relace a zachycený klíč jsou oddělená zjištění a jen jedno z nich je ztráta přihlašovacích údajů. Držte obě v oddělených větách zprávy.

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

První příkaz vypíše veřejný otisk, abyste ho porovnali s tím, co server uvádí. Druhý zviditelní kontrolu klíče hostitele místo spoléhání na výchozí hodnotu, kterou nikdo nečetl. Spusťte oba dřív, než na klíčích cokoli změníte, aby byla základní linie zdokumentovaná.

Přesměrování agenta deleguje možnost podepisovat

Když je přesměrování zapnuté, na vzdáleném hostiteli se objeví socket a místní agent odpovídá na požadavky, které jím přicházejí. Kdokoli může tento socket během relace použít, může se vůči hostitelům přijímajícím načtené identity prokázat jako vy. Žádný soukromý klíč kvůli tomu nepřechází síť.

Vystavená je schopnost, ne soubor. Proto přesměrování patří k pojmenovanému úkolu a pojmenovanému hostiteli, ne ke každému připojení, které notebook naváže. Přeskakovací hostitel, který spojení předává bez přesměrovaného agenta, obvykle potřebu úplně odstraní.

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

První vypíše, které identity agent právě drží, což se hodí vědět, než jeho socket předáte jinému stroji. Druhý se připojuje bez delegování. Třetí ukazuje vzor přeskakovacího hostitele, který často přesměrování zcela nahradí.

Vyberte reakci podle důkazů, které máte

Identita pro podepisování, o níž se má za to, že je vystavená, vyžaduje proces nahrazení a odvolání a odstranění jejího přijetí ze služeb, které jí věřily. Smazání kopie na notebooku nechá všechny ostatní kopie nedotčené. Začněte u služeb, pak ukliďte klienty.

Dočasný problém s delegováním je užší. Ukončete přesměrování, které nebylo potřeba, a s vlastníkem incidentu projděte, které relace a identity pokrývalo. Nahrazení klíče může následovat, ale rozhodují o něm důkazy, ne obavy.

Žádný pozorovaný export dokazuje jen to, že se mechanismus, kterého jste se báli, neobjevil. Nic to neříká o tom, co dalšího mohl hostitel na druhém konci toho socketu udělat.

Držte kontroly ve zprávě oddělené

Chraňte soukromý materiál, omezujte, kdo ho může požádat o podpis, udržujte ověřenou identitu protistrany. To jsou tři kontroly, které se navzájem posilují, a žádná z nich nenahrazuje jinou, když vysvětlujete, co se stalo.

Kompromitovaný notebook nebo privilegovaná aplikace na něm je třetí případ s mnohem širším dopadem. Změna trasy VPN ho neřeší a neobnoví důvěru v klíč, který mohl být přečten z disku.

Zapište, která součást byla důvěryhodná, zda bylo přesměrování zapnuté a co se skutečně pozorovalo. Právě tento záznam dělá další rozhodnutí obhajitelným místo dohadu o tom, co únik znamená.

Související články