Przekazywanie agenta SSH a kopiowanie klucza: co naprawdę wycieka

Dwa różne zdarzenia nazywa się wyciekłym kluczem SSH, i wymagają one różnych reakcji. Uwierzytelnianie kluczem publicznym wysyła klucz publiczny i podpis utworzony kluczem prywatnym, więc klucz prywatny nigdy nie jest polem żądania. Przekazywanie agenta ujawnia coś innego, bo zdalny host, który dosięga przekazanego agenta, może poprosić go o podpis, nigdy nie posiadając klucza. Traktowanie obu jako jednego zdarzenia kończy się albo bezsensowną wymianą klucza, albo delegacją, która pozostaje aktywna.

Logowanie kluczem publicznym przesyła podpis, nie klucz

Wymiana uwierzytelniająca niesie klucz publiczny użytkownika i podpis nad danymi sesji. Serwer sprawdza ten podpis kluczem, któremu już ufa, dlatego prywatna połowa może pozostać na kliencie przez niezaufaną sieć. Operator VPN obserwujący tunel i tak widzi zaszyfrowaną sesję SSH.

To opisuje protokół, a nie wiarygodność każdego punktu końcowego na drodze. Zachowaj weryfikację tożsamości hosta w nienaruszonym stanie, bo klient, który akceptuje dowolny klucz hosta, porzucił inną kontrolę niż ta, o której mówimy. Przechwycona sesja i przechwycony klucz to odrębne ustalenia, i tylko jedno z nich jest utratą poświadczeń. Trzymaj oba w osobnych zdaniach raportu.

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

Pierwsze polecenie drukuje publiczny odcisk, abyś mógł porównać go z tym, co wymienia serwer. Drugie czyni sprawdzenie klucza hosta jawnym zamiast polegać na wartości domyślnej, której nikt nie przeczytał. Uruchom oba, zanim zmienisz cokolwiek w kluczach, aby linia bazowa została udokumentowana.

Przekazywanie agenta deleguje możliwość podpisywania

Gdy przekazywanie jest włączone, na zdalnym hoście pojawia się gniazdo, a lokalny agent odpowiada na żądania przychodzące przez nie. Ktokolwiek może użyć tego gniazda podczas sesji, może uwierzytelnić się jako ty wobec hostów akceptujących załadowane tożsamości. Żaden klucz prywatny nie przekracza sieci, aby to działało.

Ujawnieniem jest zdolność, a nie plik. Dlatego przekazywanie należy do nazwanego zadania i nazwanego hosta, a nie do każdego połączenia, które nawiązuje laptop. Host przeskoku, który przekazuje połączenie bez przekazanego agenta, zwykle całkowicie usuwa potrzebę.

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

Pierwsze wymienia tożsamości, które agent obecnie trzyma, co warto wiedzieć przed oddaniem jego gniazda innej maszynie. Drugie łączy się bez delegacji. Trzecie pokazuje wzorzec hosta przeskoku, który często całkowicie zastępuje przekazywanie.

Wybierz reakcję na podstawie dowodów, które masz

Tożsamość podpisująca uznana za ujawnioną wymaga procesu wymiany i unieważnienia oraz usunięcia jej akceptacji z usług, które jej ufały. Usunięcie kopii na laptopie pozostawia każdą inną kopię nietkniętą. Zacznij od usług, potem uporządkuj klientów.

Przejściowy problem z delegacją jest węższy. Zakończ przekazywanie, które nie było potrzebne, i przejrzyj z właścicielem incydentu, które sesje i tożsamości obejmowało. Wymiana klucza może nastąpić, ale decydują o tym dowody, a nie niepokój.

Brak zaobserwowanego eksportu dowodzi tylko, że mechanizm, którego się bałeś, nie wystąpił. Nie mówi nic o tym, co jeszcze mógł zrobić host po drugiej stronie tego gniazda.

Trzymaj mechanizmy kontroli osobno w raporcie

Chroń materiał prywatny, ograniczaj, kto może poprosić go o podpis, utrzymuj zweryfikowaną tożsamość drugiej strony. To trzy mechanizmy, które się wzmacniają, i żaden nie zastępuje innego, gdy wyjaśniasz, co się stało.

Skompromitowany laptop lub uprzywilejowana aplikacja na nim to trzeci przypadek o znacznie szerszym zasięgu. Zmiana trasy VPN tego nie rozwiązuje i nie przywraca zaufania do klucza, który mógł zostać odczytany z dysku.

Zapisz, któremu komponentowi ufano, czy przekazywanie było włączone i co faktycznie zaobserwowano. To właśnie ten zapis czyni następną decyzję obronną, a nie domysłem o tym, co oznacza wyciek.