Kto tak naprawdę widzi Twoje hasło SSH w niezaufanej VPN?

Poprowadź sesję SSH przez VPN, którego nie administrujesz, a hasło nadal należy do serwera SSH, nie do sieci pomiędzy. Jeśli transport do zweryfikowanego hosta jest należycie chroniony, pasywny obserwator na tej drodze nie otrzymuje hasła w czytelnej postaci. Ale zmień jeden warunek, a odpowiedź się zmienia: niezweryfikowany host, osłabiona lista szyfrów albo przejęta stacja robocza dają różne wyniki. Wykonaj poniższe kontrole po kolei i każdą traktuj jako warunek zatrzymania.

Nazwij odbiorcę, zanim cokolwiek wpiszesz

Pole hasła podróżuje wewnątrz komunikatu uwierzytelniania, a ten komunikat podróżuje wewnątrz szyfrowanego transportu. Poufność jest właściwością transportu, co oznacza, że zależy od wynegocjowania ochrony i od wynegocjowania jej z hostem, który miałeś na myśli. Właśnie drugą połowę ludzie pomijają. Połączenie szyfrowane do oszusta jest jednocześnie poufne i bezużyteczne. Logowanie do VPN nie dowodzi niczego o hoście SSH, a reputacja dostawcy nie zastępuje sprawdzenia klucza.

Trzymaj oba kierunki osobno w głowie. Klucz hosta odpowiada na pytanie, do którego serwera dotarłeś. Uwierzytelnianie hasłem lub kluczem odpowiada na pytanie, którego użytkownika akceptuje serwer. Poprawa drugiego nigdy nie naprawia pierwszego.

Sprawdź tożsamość hosta, wpis i negocjację

Zacznij na kliencie od wpisu, który już masz. Opublikowany odcisk palca porównany z zaufanym źródłem oraz wpis known_hosts, który wciąż się zgadza, dają jedyny dowód, który ma znaczenie przed rozpoczęciem uwierzytelniania.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Po stronie serwera wydrukuj odciski palca, które zamierzasz opublikować, zamiast kopiować je z pamięci. Rozprowadzanie ich poza kanałem jest całą istotą; odcisk palca wklejony z tego samego kanału czatu co nazwa hosta dowodzi tylko, że oba pochodzą z tego samego miejsca.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Wynegocjowane algorytmy pochodzą z przecięcia obu stron. Jeśli konfiguracja klienta przypina przestarzałą wymianę kluczy, aby dotrzeć do starego urządzenia, ten wybór dotyczy każdego hosta, z którym rozmawia, więc ogranicz go do tego hosta, a nie globalnie.

Przeczytaj metody, które serwer faktycznie akceptuje

Wiedza o tym, jakie metody uwierzytelniania dopuszcza serwer, mówi ci, do czego hasło w ogóle służy. Host akceptujący tylko klucze publiczne nie ma wymiany haseł do ochrony, a host, który nadal akceptuje hasła, zasługuje na świadomą decyzję, a nie odziedziczoną wartość domyślną.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Przełączenie użytkownika na uwierzytelnianie kluczem usuwa hasło tego użytkownika z tej wymiany. Nie czyni to przejętej stacji roboczej bezpieczną ani nie czyni niezaufanej sesji zdalnej nieszkodliwą. To różne ryzyka z różnymi środkami kontroli. Zdecyduj też o przekazywaniu agenta. Przekazanie agenta do niezaufanego hosta daje temu hostowi możliwość używania twoich kluczy przez czas trwania sesji, a to większe narażenie niż kwestia hasła, od której wszystko się zaczęło.

Traktuj ostrzeżenie o kluczu hosta jako krok incydentu

Gdy klient ostrzega, że identyfikacja hosta się zmieniła, zatrzymaj się i zweryfikuj kanałem, który nie przechodzi tą samą drogą sieciową. Porównaj odcisk palca z konsolą serwera lub z operatorem, który go odbudował. Usunięcie starego wpisu, aby uciszyć ostrzeżenie, jest jedynym działaniem, którego należy odmówić. Wyrzuca dowód i zamienia możliwe przechwycenie w zwykłe logowanie.

Jeśli host został legalnie odbudowany, usuń nieaktualny wpis dopiero po potwierdzeniu nowego odcisku palca, następnie połącz się ponownie i sprawdź negocjację jeszcze raz. Zapisz zmianę z datą i powodem, ponieważ następna osoba zobaczy to samo ostrzeżenie i musi wiedzieć, że zostało rozwiązane.

Czego ten przewodnik nie obejmuje

Operator VPN obserwujący ruch to nie to samo co oprogramowanie z lokalnymi uprawnieniami na twojej maszynie. Przejęcie punktu końcowego, wroga wtyczka przeglądarki lub rejestrator klawiatury leżą poniżej wszystkiego, co SSH może wynegocjować, i żaden tunel tego nie zmienia. Jeśli stacja robocza jest podejrzana, postępuj zgodnie z procedurą incydentu, zamiast testować tajność, łącząc się ponownie przez inne wyjście. Ponowne połączenie dowodzi, że droga sieciowa się zmieniła, i niczego o punkcie końcowym.

Zakończ zwykłym przypadkiem: zweryfikowany host, chroniony transport, świadomie wybrana metoda uwierzytelniania i żadne przekazywanie, którego nie potrzebowałeś. Ta kombinacja jest odpowiedzią na pytanie z tytułu, a to cztery decyzje, nie jedna.