Ping działa, ale SSH zawodzi przez VPN: który etap się zepsuł?
Jedna szczegółowa próba rozdziela osiągalność TCP, transport SSH, tożsamość hosta, logowanie użytkownika i uprawnienie sesji, żebyś przestał zgadywać przy tunelu.
Odpowiedzi ping i odrzucone logowanie SSH mogą być prawdziwe jednocześnie, a ta para nie obciąża tunelu. Odpowiedzi echa i połączenie TCP do portu 22 to różne testy z różnymi selektorami, różnymi politykami i często różnymi celami. Zarejestruj jedną zamierzoną próbę SSH, a potem nazwij ostatni etap, do którego dotarła. Ten jeden artefakt zastępuje tuzin spekulacyjnych zmian konfiguracji.
Zarejestruj jedną próbę, nie sesję dłubania
Uruchom klienta raz ze szczegółową diagnostyką, wyłączonym udostępnianiem połączenia i ograniczonym limitem czasu połączenia. Wyłączenie udostępniania ma znaczenie, bo wcześniej uwierzytelnione połączenie główne odpowie za nową próbę i ukryje usterkę, której ścigasz.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Zachowaj cel, rodzinę adresów, znacznik czasu i ostatni błąd, który nie jest sekretem. Flaga IPv4 oznacza też, że ta próba nic nie mówi o ścieżce IPv6 do tej samej nazwy, więc nie uogólniaj z niej. Zapisz, skąd wykonano próbę. Sprawdzenie na bramie VPN to nie ten sam punkt widzenia co laptop za nią, a większość sprzeczności w tych zgłoszeniach bierze się z mieszania obu.
Etap pierwszy i drugi: TCP przed SSH
Pierwszą granicą jest osiągalność gniazda: adres, port i trasa, którą pakiet faktycznie podąża. Jeśli połączenie TCP nigdy się nie nawiąże, nic nad nim jeszcze nie istnieje, a klucze hosta i konta są nieistotne.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Skoreluj zapis z próbą klienta. Wychodzący SYN i nic, co wraca, wskazuje na filtrowanie, selektory lub brakującą trasę po drugiej stronie; odpowiedź z resetem wskazuje na coś, co aktywnie odmawia, a nie odrzuca. Drugą granicą jest sama wymiana protokołu SSH. Połączenie TCP, które się nawiązuje, a potem zawiesza, minęło osiągalność i weszło w negocjację, odpowiedź serwera albo obsługę pakietów. To inne śledztwo i właśnie tam problemy związane z rozmiarem po raz pierwszy stają się prawdopodobne.
Etap trzeci: czyj klucz odpowiedział
Gdy transport jest podniesiony, klient weryfikuje klucz hosta serwera. Odrzucenie tutaj to stwierdzenie o tożsamości, nie o kryptografii: druga strona przedstawiła klucz, którego twoja polityka nie akceptuje. Potraktuj to jako warunek zatrzymania i zweryfikuj poza kanałem, przez konsolę lub operatora, który odbudował hosta. Usunięcie zapamiętanego wpisu, żeby wyczyścić ostrzeżenie, to jedyny skrót, którego należy odmówić, bo niszczy dowód, że coś odpowiedziało nieoczekiwanie.
Jeśli host naprawdę został odbudowany, usuń stary wpis dopiero po potwierdzeniu nowego odcisku i zanotuj datę oraz powód. Następny inżynier napotka to samo ostrzeżenie i potrzebuje tego kontekstu.
Etap czwarty i piąty: konto kontra uprawnienie
Uwierzytelnianie to czwarta granica. Odrzucone dane logowania oznaczają, że serwer ocenił próbę i ją odrzucił; sprawdź konto, typ danych logowania akceptowany przez serwer i własną politykę serwera, a nie hasło VPN. Piątą granicą jest autoryzacja po udanym logowaniu. Uwierzytelnionemu użytkownikowi nadal można odmówić powłoki, polecenia, podsystemu lub przekazywania, a te odmowy wyglądają jak usterki dla kogoś, kto czyta tylko ostatnią linię klienta.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Zatrzymaj się po kilku nieudanych próbach hasła. Powtarzane domysły tworzą blokady, które potem wyglądają jak druga, niezwiązana usterka, i kosztują więcej czasu niż pierwotne zgłoszenie.
Wycofanie i zapis, który prowadzisz
Zmieniaj jedną rzecz naraz i zapisuj, co zmieniłeś, zanim przetestujesz ponownie. Jeśli zmiana pogarsza próbę, natychmiast ją wycofaj, zamiast dokładać kolejną poprawkę. Powtórz pierwotną operację z pierwotnego klienta i kontekstu. Udane logowanie z innej maszyny, w innej rodzinie adresów, nie jest odtworzeniem i nie dowodzi poprawki.
Oczyść to, czym się dzielisz. Szczegółowe wyjście klienta może zawierać nazwy wewnętrzne, etykiety kont, ścieżki kluczy i identyfikatory kluczy publicznych, więc publikuj wniosek etapowy zamiast surowego śladu.