SSH-Bastion-Host betreiben: ProxyJump auf dem Client und Einschränkung dessen, was der Jump-Host weiterleiten darf

Ziel

Benutzern den Zugriff auf interne Hosts über einen einzelnen SSH-Jump-Host ermöglichen, ohne dem SSH-Server dieses Jump-Hosts eine Blankovollmacht zu geben, Datenverkehr beliebig weiterzuleiten.

Voraussetzungen

Ein Bastion-Host, der aus dem Netz des Clients erreichbar ist und von dem aus SSH-Zugriff auf interne Hosts besteht; Administratorzugriff sowohl auf die ssh_config des Clients als auch auf die sshd_config der Bastion.

Schritte

1. Auf dem Client (bzw. in dessen ~/.ssh/config) den Zwischenschritt mit ProxyJump konfigurieren: ein Host-Block für das interne Ziel mit ProxyJump bastion-user@bastion-host und dem tatsächlichen HostName. Die Option nimmt einen oder mehrere Jump-Proxys entgegen; mehrere, durch Kommas getrennte Proxys werden nacheinander durchlaufen, eine Kette von Bastions ist also ebenfalls möglich.
2. In der sshd_config der Bastion das Forwarding nicht auf dem Standardwert belassen: AllowTcpForwarding legt fest, ob TCP-Forwarding erlaubt ist (Standard yes, lokal und remote). ProxyJump veranlasst die Bastion, eine TCP-Verbindung zum Ziel zu öffnen (ssh -W), was sshd als lokales Forwarding behandelt; mit AllowTcpForwarding no funktioniert es daher nicht. no als globalen Standard für die eigenen Logins der Administratoren beibehalten und Jump-Benutzern nur local gewähren (Schritt 4), damit Remote-Forwarding (-R) ausgeschaltet bleibt; zusätzlich X11Forwarding no und AllowAgentForwarding no setzen.
3. Mit PermitOpen eingrenzen, wohin Jumps führen dürfen. Die Option legt als host:port-Paare fest, zu welchen Zielen TCP-Port-Forwarding erlaubt ist, zum Beispiel PermitOpen 10.0.1.10:22 10.0.1.11:22. Sie gilt auch für ProxyJump, und die Ziele werden so verglichen, wie der Client sie benennt; deshalb dieselben Namen oder Adressen verwenden wie im HostName der Clients.
4. Die Ausnahme in einen Match-Block am Dateiende legen, zum Beispiel Match Group jump-users, gefolgt von eingerückten Zeilen mit AllowTcpForwarding local, PermitOpen ..., PermitTTY no und ForceCommand /usr/sbin/nologin (Jump-Verbindungen öffnen keine Shell, daher verhindert dies nur interaktive Logins). Ein Match-Block leitet einen bedingten Abschnitt ein, dessen Schlüsselwörter die Einstellungen des globalen Abschnitts überschreiben, bis die nächste Match-Zeile oder das Dateiende folgt.
5. Protokollieren, was durchgeleitet wird: LogLevel VERBOSE erfasst den Schlüssel-Fingerprint jedes Logins; von PermitOpen abgelehnte Forwarding-Anfragen werden auf der Standardstufe protokolliert, erlaubte Ziele erscheinen dagegen nur auf den DEBUG-Stufen.
6. Mit sshd -t validieren, eine bestehende Root-Sitzung offen halten und dann neu laden (systemctl reload ssh unter Debian und Ubuntu, sshd unter RHEL; bestehende Sitzungen bleiben bestehen). Anschliessend in einem zweiten Terminal prüfen, dass der ProxyJump-Pfad weiterhin funktioniert und dass ein nicht aufgeführtes Ziel abgelehnt wird.

Erwartetes Ergebnis

Ein Jump-Benutzer erreicht über ProxyJump nur die aufgeführten internen Hosts und erhält keine Shell auf der Bastion; Forwarding zu einem nicht aufgeführten Ziel oder von einem Konto ohne die Match-Ausnahme schlägt fehl und wird mit Benutzer und Ziel protokolliert.

Grenzen und Prüfbasis

Die Einschränkung des Forwardings auf der Bastion beschränkt nicht, was die internen Zielhosts selbst erlauben; dort ist dieselbe Prüfung vorzunehmen. In sshd_config(5) steht, dass das Abschalten von Forwarding die Sicherheit nicht erhöht, solange Benutzer Shell-Zugriff haben, da sie eigene Forwarder ausführen können. Match-Blöcke werden in der Reihenfolge der Datei ausgewertet, und bei den meisten Schlüsselwörtern gilt der zuerst ermittelte Wert; nach jeder Änderung mit einem nicht privilegierten Konto testen, nicht nur als Administrator.