Klucz SSH skopiowany czy agent przekazany dalej? Dwa różne ryzyka

Logowanie korzystające z klucza SSH przez VPN nie oznacza, że klucz prywatny został przekazany operatorowi sieci, i to uspokojenie jest węższe, niż ludzie słyszą. Uwierzytelnianie kluczem publicznym wysyła klucz publiczny i podpis, który klient tworzy lokalnie. Przekazywanie agenta to inny układ z inną ekspozycją, i może pozostawić użyteczną zdolność uwierzytelniania na maszynie, której nie kontrolujesz. Odpowiedź, którą jesteś winien, zależy od tego, które z tych dwóch naprawdę się wydarzyło.

Co wysyła uwierzytelnianie kluczem publicznym

W standardowej metodzie klucza publicznego klient oferuje klucz publiczny, serwer decyduje, czy akceptuje ten klucz, a klient podpisuje wyzwanie kluczem prywatnym, który pozostaje w jego pliku lub jego agencie. Przez sieć przechodzi klucz publiczny i wynikający z niego podpis. Nic w tej wymianie nie wymaga, aby serwer, tunel lub ktokolwiek na drodze posiadał materiał prywatny.

Specyfikacja uwierzytelniania definiuje ten dowód, a klucz prywatny nie jest polem w żądaniu.

To stwierdzenie o protokole, nie referencja charakteru dla każdego zaangażowanego punktu końcowego. Sprawdzanie tożsamości hosta nadal musi być nienaruszone, ponieważ serwer, który nie potrafi dowieść, kim jest, może zbierać podpisy w celu, którego nie zamierzałeś. Wynajęta VM, odziedziczony bastion i laptop z nieznanym rozszerzeniem to trzy odrębne pytania o zaufanie. Trzymaj je oddzielnie od kryptograficznego, które jest naprawdę rozstrzygnięte.

Co deleguje przekazywanie agenta

Przekazywanie agenta otwiera kanał od zdalnego hosta z powrotem do agenta na twojej maszynie, więc procesy na tym hoście mogą prosić agenta o podpisanie, nigdy nie posiadając klucza prywatnego. Klucz zostaje tam, gdzie jest, a zdolność nie. Wszystko, co może dotrzeć do tego przekazanego gniazda na zdalnym hoście, przez czas trwania sesji, może żądać operacji uwierzytelniania jako jedna z załadowanych tożsamości. To delegowane uprawnienie, dlatego przekazywanie zasługuje na węższą politykę niż przekazanie klucza publicznego.

Skopiowany plik klucza to ujawnienie. Przekazany agent to zezwolenie, i oba wymagają różnych odpowiedzi.

Włącz przekazywanie dla nazwanej potrzeby i nazwanych hostów, i sprawdź, co klient naprawdę robi, a nie co wydaje się mówić konfiguracja. Liczą się efektywne ustawienia, ponieważ blok hosta po cichu nadpisuje globalną wartość domyślną. Ta sama logika dotyczy strony serwera, który może całkowicie odmówić przekazywania, gdy wdrożenie nigdy go nie potrzebuje.

Przeczytaj dowody, zanim wybierzesz odpowiedź

Jeśli uważa się, że plik klucza prywatnego lub równoważna tożsamość podpisu została ujawniona, odpowiedzią jest wymiana i unieważnienie przez proces twojej organizacji, plus usunięcie jego akceptacji z każdej usługi, która mu ufała. Usunięcie jednej lokalnej kopii nie unieważnia kopii, których nie widzisz.

Jeśli obawą jest tymczasowy dostęp agenta, odpowiedź jest węższa: zatrzymaj niepotrzebne delegowanie, przejrzyj zaangażowane sesje i tożsamości, i pozwól właścicielowi incydentu zdecydować, czy wymiana jest uzasadniona. Dowody mają tu znaczenie, ponieważ brak zaobserwowanego eksportu nie dowodzi, że nie doszło do nadużycia uwierzytelniania, a sama zmiana ścieżki nie jest diagnozą skradzionego klucza. Zapisz, któremu komponentowi ufano, czy przekazywanie było włączone i co faktycznie zaobserwowano. Potem wybierz odpowiedź pasującą do tego zapisu, a nie najbardziej dramatyczną dostępną.

ssh-add -l
ssh -G host.example | grep -i forwardagent

Uruchom je przed zmianą i po niej, aby porównanie coś znaczyło. Sesja ustanowiona wcześniej zachowuje delegowanie, które jej przyznano, cokolwiek ustawienia mówią teraz.

Dwie kontrole, których nie można zamienić

Ochrona materiału prywatnego, ograniczanie tego, kto może prosić o jego podpis, i weryfikacja tożsamości drugiej strony to trzy powiązane kontrole, i żadna nie zastępuje innej. Zespół, który usuwa przekazywanie bez sprawdzania kluczy hostów, naprawił połowę problemu. Zespół, który rotuje klucz, bo zmieniła się trasa, nie naprawił niczego.

Skompromitowany punkt końcowy to czwarte pytanie, ponieważ uprzywilejowane oprogramowanie na twojej własnej maszynie może zrobić znacznie więcej niż obserwować pakiety.

Posortuj incydent do tych kategorii, zanim czegokolwiek dotkniesz, i daj każdej właściciela. Prowadź krótki zapis tego, czemu ufano, co delegowano i co zweryfikowano, ponieważ ten zapis sprawia, że następny przegląd jest tani zamiast kolejnej debaty. Jeśli jakakolwiek kategoria jest nieznana, napisz nieznana, zamiast zakładać łagodny przypadek. Rozróżnienie jest praktyczne, nie akademickie: decyduje, czy wymieniasz poświadczenie, unieważniasz sesję, czy po prostu przestajesz przekazywać.