Ping funktioniert, SSH scheitert über das VPN: Welche Stufe ist kaputt?
Ein einziger ausführlicher Versuch trennt TCP-Erreichbarkeit, SSH-Transport, Host-Identität, Benutzeranmeldung und Sitzungsberechtigung, damit Sie beim Tunnel aufhören zu raten.
Ping-Antworten und eine abgelehnte SSH-Anmeldung können gleichzeitig zutreffen, und das Paar beschuldigt nicht den Tunnel. Echo-Antworten und eine TCP-Verbindung zu Port 22 sind verschiedene Tests mit verschiedenen Selektoren, verschiedenen Richtlinien und oft verschiedenen Zielen. Erfassen Sie einen bewussten SSH-Versuch und benennen Sie dann die letzte erreichte Stufe. Dieses eine Artefakt ersetzt ein Dutzend spekulativer Konfigurationsänderungen.
Erfassen Sie einen Versuch, keine Sitzung voller Stochern
Starten Sie den Client einmal mit ausführlicher Diagnose, deaktivierter Verbindungsfreigabe und begrenztem Verbindungs-Timeout. Die Freigabe zu deaktivieren ist wichtig, weil eine zuvor authentifizierte Master-Verbindung sonst für den neuen Versuch antwortet und den Fehler verbirgt, den Sie verfolgen.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Behalten Sie Ziel, Adressfamilie, Zeitstempel und den letzten nicht geheimen Fehler. Das IPv4-Flag bedeutet außerdem, dass dieser Versuch nichts über einen IPv6-Pfad zum selben Namen sagt, also verallgemeinern Sie nicht daraus. Notieren Sie, von wo aus der Versuch gemacht wurde. Eine Prüfung auf dem VPN-Gateway ist nicht derselbe Blickwinkel wie ein Laptop dahinter, und die meisten Widersprüche in diesen Tickets entstehen aus der Vermischung beider.
Stufen eins und zwei: TCP vor SSH
Die erste Grenze ist die Erreichbarkeit des Sockets: eine Adresse, ein Port und eine Route, der das Paket tatsächlich folgt. Wenn die TCP-Verbindung nie zustande kommt, existiert darüber noch nichts, und Hostschlüssel und Konten sind irrelevant.
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'Korrelieren Sie die Aufzeichnung mit dem Client-Versuch. Ein abgehendes SYN, auf das nichts zurückkommt, deutet auf Filterung, Selektoren oder eine fehlende Route auf der Gegenseite hin; eine Antwort mit Reset deutet auf etwas hin, das aktiv ablehnt statt zu verwerfen. Die zweite Grenze ist der SSH-Protokollaustausch selbst. Eine TCP-Verbindung, die zustande kommt und dann stockt, hat die Erreichbarkeit hinter sich gelassen und ist in Aushandlung, Serverantwort oder Paketverarbeitung eingetreten. Das ist eine andere Untersuchung, und dort werden größenbezogene Probleme erstmals plausibel.
Stufe drei: Wessen Schlüssel antwortete
Sobald der Transport steht, prüft der Client den Hostschlüssel des Servers. Eine Ablehnung hier ist eine Aussage über Identität, nicht über Kryptografie: Der Peer hat einen Schlüssel vorgelegt, den Ihre Richtlinie nicht akzeptiert. Behandeln Sie das als Abbruchbedingung und prüfen Sie außerhalb des Bandes, an der Konsole oder beim Betreiber, der den Host neu aufgebaut hat. Den gemerkten Eintrag zu löschen, um die Warnung zu beseitigen, ist die eine Abkürzung, die Sie ablehnen sollten, weil sie den Beweis zerstört, dass etwas Unerwartetes geantwortet hat.
Wurde der Host wirklich neu aufgebaut, entfernen Sie den veralteten Eintrag erst, nachdem der neue Fingerabdruck bestätigt ist, und notieren Sie Datum und Grund. Der nächste Ingenieur trifft dieselbe Warnung und braucht diesen Kontext.
Stufen vier und fünf: Konto gegen Berechtigung
Authentifizierung ist die vierte Grenze. Abgelehnte Anmeldedaten bedeuten, dass der Server den Versuch bewertet und abgelehnt hat; prüfen Sie das Konto, die Art der Anmeldedaten, die der Server akzeptiert, und die eigene Richtlinie des Servers statt das VPN-Passwort. Die fünfte Grenze ist die Autorisierung nach erfolgreicher Anmeldung. Einem authentifizierten Benutzer kann dennoch eine Shell, ein Befehl, ein Subsystem oder eine Weiterleitung verweigert werden, und diese Ablehnungen sehen für jemanden, der nur die letzte Zeile des Clients liest, wie Fehler aus.
| 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 |
Hören Sie nach ein paar fehlgeschlagenen Passwortversuchen auf. Wiederholte Ratespiele erzeugen Sperren, die dann wie ein zweiter, unabhängiger Fehler aussehen und mehr Zeit kosten als das ursprüngliche Ticket.
Rückabwicklung und die Aufzeichnung, die Sie behalten
Ändern Sie jeweils eine Sache und notieren Sie vor dem erneuten Test, was Sie geändert haben. Verschlechtert eine Änderung den Versuch, nehmen Sie sie sofort zurück, statt eine weitere Korrektur daraufzustapeln. Wiederholen Sie den ursprünglichen Vorgang vom ursprünglichen Client und im ursprünglichen Kontext. Eine erfolgreiche Anmeldung von einer anderen Maschine, in einer anderen Adressfamilie, ist keine Reproduktion und beweist den Fix nicht.
Bereinigen Sie, was Sie teilen. Ausführliche Client-Ausgaben können interne Namen, Kontobezeichnungen, Schlüsselpfade und öffentliche Schlüsselkennungen enthalten, veröffentlichen Sie deshalb die stufenweise Schlussfolgerung statt einer Rohspur.