SSH über einen zweiten privaten Pfad bei weiterhin aktivem VPN

Eine Maschine erreicht eine andere über ein VPN, und nun möchte jemand dieselbe Shell über ein privates Netz eines Anbieters nutzen. Die Route existiert, der Ping gelingt, und SSH verweigert trotzdem. Die übliche Ursache ist, dass der Daemon nie auf der neuen Adresse gelauscht hat, also gibt es nichts, womit man sich verbinden könnte. Das ist ein Adressbindungsproblem, bevor es ein Firewallproblem ist.

Warum eine neue Route keinen neuen Listener erzeugt

Ein lauschender Socket wird von einem Prozess erzeugt, der die Adressen benennt, die er annehmen wird. Eine Route sagt Paketen nur, wohin sie reisen sollen; sie erzeugt am Ziel keinen Listener. Wenn sshd mit einem einzigen ListenAddress konfiguriert ist, werden Verbindungen zu jeder anderen lokalen Adresse abgelehnt, selbst wenn die Schnittstelle aktiv ist. Dasselbe gilt für eine Socket-Unit, die den Port besitzt, und deshalb ist die erste Prüfung immer, was tatsächlich lauscht.

Vergleichen Sie die beiden Pfade anhand der Zieladresse statt anhand des Schnittstellennamens. Ein Client verbindet sich zu einer Adresse, und diese Adresse muss gebunden sein, bevor irgendeine Firewallregel relevant wird.

Listen Sie die Adressen und die Listener auf

Bevor Sie etwas bearbeiten, halten Sie die Adressen auf dem Host und die derzeit vorhandenen Sockets fest.

ip -br addr
ss -ltnp | grep ':22'

Die Adressliste zeigt, welche private Adresse echt ist und auf welcher Schnittstelle, während die Socket-Liste zeigt, ob etwas daran gebunden ist. Ein Listener auf 0.0.0.0:22 nimmt bereits jede Adresse an, eine neue Bindung bringt also nichts. Ein Listener auf einer bestimmten Adresse erklärt die Ablehnung sofort. Wenn der Port zu einer Socket-Unit statt zum Daemon gehört, ist die Daemon-Konfiguration nicht die ganze Geschichte.

Fügen Sie die Bindung hinzu und behalten Sie die alte

OpenSSH akzeptiert mehrere ListenAddress-Einträge, daher kann der VPN-Pfad bleiben, während der private hinzugefügt wird. Testen Sie die Datei, bevor Sie sie neu laden.

sshd -t
systemctl reload sshd

Ein fehlgeschlagener Konfigurationstest lässt den laufenden Daemon unberührt, und genau das wollen Sie, während Sie über den Pfad verbunden sind, den Sie bearbeiten. Behalten Sie den vorhandenen Eintrag, fügen Sie die neue lokale Adresse hinzu und bestätigen Sie, dass der Dienst neu lädt, ohne die aktuelle Sitzung zu verlieren. Bei socket-aktivierten Installationen fügen Sie die Adresse stattdessen der Socket-Unit hinzu und laden diese Unit neu. Lesen Sie dann die Listener-Liste erneut, denn eine Bindung, die nie auftauchte, bedeutet, dass die falsche Komponente bearbeitet wurde.

Prüfen Sie die neue Sitzung, bevor Sie die alte schließen

Verbinden Sie sich mit der neuen Adresse, während die ursprüngliche Sitzung noch offen ist, und nutzen Sie ausführliche Ausgaben, um zu sehen, welche Adresse und welcher Schlüssel verwendet wurden. Halten Sie die ursprüngliche Sitzung offen, bis die Prüfung zweimal gelingt.

ssh -v [email protected]

Lesen Sie die Debug-Zeilen zur Zieladresse und zum vorgelegten Hostschlüssel. Bestätigen Sie den Fingerabdruck des Hostschlüssels anhand eines Werts, dem Sie bereits vertrauen, statt einen unbekannten Schlüssel anzunehmen, weil das Netz als privat beschrieben wird. Das neue Ziel braucht einen eigenen known_hosts-Eintrag, und das ist zu erwarten. Erst wenn der private Pfad funktioniert, sollte die alte Verwaltungssitzung geschlossen werden.

SSH schützt den Transport, macht aber zwei Netze nicht von sich aus gleichwertig. Entscheiden Sie, ob das Vertrauen des privaten Transits zu den Daten passt, bevor Sie sich darauf verlassen.