SSH-Bastion und Jump-Host: Funktion, Härtung und Mesh-VPN-Ablösung

Fernzugriff ohne offene SSH-Ports planen? WZ-IT baut souveräne Remote-Management-Plattformen - vom gehärteten Jump-Host bis zum identitätsbasierten Mesh. Zur Remote-Management-Plattform

Ein SSH-Bastion- bzw. Jump-Host (Sprungserver) ist ein einzelner, gehärteter Server, über den der gesamte SSH-Zugriff auf ein internes Netz läuft. Statt jeden Server direkt aus dem Internet erreichbar zu machen, ist nur der Bastion exponiert; alle Zielsysteme liegen ohne öffentliche IP dahinter. Der moderne, sichere Weg dorthin ist ProxyJump (ssh -J), nicht Agent-Forwarding. Dieser Beitrag zeigt, wie ein Jump-Host funktioniert, wie Sie ihn härten und wann ein Mesh-VPN bzw. ZTNA den Sprungserver ablöst.

Inhaltsverzeichnis

• Wie ein Jump-Host funktioniert
• ProxyJump statt Agent-Forwarding
• Den Bastion-Host härten
• Public-Bastion oder internes Sprungbrett
• Bastion oder Mesh-VPN: wann der Sprungserver bleibt
• Schritt für Schritt: Grundkonfiguration
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Wie ein Jump-Host funktioniert

Der Jump-Host ist ein bewusst gesetzter Engpass (Choke Point): Alle SSH-Verbindungen ins interne Netz laufen über diesen einen Server, sodass Sie genau eine Stelle absichern, überwachen und protokollieren müssen. Die internen Zielsysteme haben keine öffentliche IP und akzeptieren SSH nur aus dem internen Segment.

Technisch realisiert man das heute mit ProxyJump. Der OpenSSH-Client öffnet zunächst eine Verbindung zum Bastion und baut darüber einen TCP-Forward zum Zielsystem auf. Die eigentliche SSH-Sitzung ist Ende-zu-Ende zwischen Ihrem Rechner und dem Ziel verschlüsselt - der Bastion leitet nur den Datenstrom weiter und sieht weder Klartext noch Ihren Schlüssel. ProxyJump ist seit OpenSSH 7.3 (2016) verfügbar und löst das ältere, umständlichere ProxyCommand ab (openssh.com). Aktuell ist OpenSSH 10.3 (April 2026); bereits seit OpenSSH 10.0 (April 2025) ist der Authentifizierungs-Code in ein separates sshd-auth-Binary mit eigener Adressraum-Isolation ausgelagert (openssh.com/txt/release-10.0).

Auf der Kommandozeile genügt der Schalter -J:

# Direkt durch den Bastion zum internen Ziel
ssh -J jump.example.com 10.0.10.20

# Mehrere Sprünge (jeder Hop muss nur den nächsten erreichen)
ssh -J jump1.example.com,jump2.internal 10.0.20.30

Serverseitig ist dafür keine Sonderkonfiguration nötig - es reicht, dass der Bastion das Ziel erreicht und Sie SSH-Zugriff auf den Bastion haben. Auch scp, rsync und sftp funktionieren transparent über denselben Pfad.

ProxyJump statt Agent-Forwarding

Lange war Agent-Forwarding (ForwardAgent yes) das Mittel der Wahl, um sich vom Bastion aus an internen Hosts anzumelden. Es ist jedoch riskant: Solange Ihre Sitzung läuft, kann jemand mit Root- oder Dateizugriff auf dem Sprungserver den weitergeleiteten Agent-Socket ansprechen. Das private Schlüsselmaterial lässt sich zwar nicht auslesen, aber der Angreifer kann den Agent dazu bringen, Authentifizierungs-Challenges zu signieren - und sich damit gegenüber allen Servern, die Ihren Schlüssel akzeptieren, als Sie ausgeben (man.openbsd.org: ssh_config).

ProxyJump ist hier die klar sicherere Variante: Statt den Agent weiterzureichen, leitet der Client nur stdin/stdout durch den Bastion. Ihr Schlüssel bleibt auf der Workstation, der Sprungserver bekommt ihn nie zu Gesicht. Ein kompromittierter Bastion kann Ihre Identität dann nicht missbrauchen.

Praxisempfehlung: Auf dem Bastion AllowAgentForwarding no setzen. Agent-Forwarding nur dort einsetzen, wo es wirklich nötig ist (etwa ein Git-Push vom Zielsystem) - und auch dann lieber gezielt und kurzlebig.

Den Bastion-Host härten

Weil der Bastion der einzige Eintrittspunkt ist, muss er besonders robust sein. Die wichtigsten Maßnahmen:

• Key-only-Authentifizierung: PasswordAuthentication no, PermitRootLogin no. Bevorzugt ed25519-Schlüssel (in OpenSSH 10.x der Standard-Schlüsseltyp).
• Zweiter Faktor (MFA): AuthenticationMethods publickey,keyboard-interactive in Kombination mit einem PAM-TOTP-Modul. Noch sauberer ist die Anbindung an einen Identity Provider per SSO und MFA - zum Beispiel mit Authentik oder Keycloak.
• Funktionen einschränken: X11Forwarding no, PermitTunnel no, AllowTcpForwarding nur wo nötig. Für Automations- oder Transferkonten ForceCommand oder eine eingeschränkte Shell, damit kein interaktiver Zugriff und kein Port-Forwarding möglich ist.
• Quell-IP-Filterung: Eingehend nur Port 22 von bekannten Netzen, ergänzt um Match Address für feinere Regeln.
• Logging und Recording: sshd-Logs und optional eine Session-Aufzeichnung (auditd, tlog) an ein externes SIEM ausleiten. Logs gehören off-host - lokal könnte ein Angreifer mit Root sie verändern oder löschen. Wir nutzen dafür Wazuh; die Grundlagen dazu im Leitfaden RBAC und Audit für Fernzugriff.
• Kurzlebige Zertifikate statt Schlüsselwildwuchs: Eine SSH-CA (etwa step-ca oder Vault) stellt kurzlebige Nutzerzertifikate aus. Das beseitigt verteilte authorized_keys und manuelle Rotation.
• Patchen und überwachen: Ein öffentlicher Bastion ist ein Angriffsziel. Aktuelle OpenSSH-Version fahren und per CVE-Monitoring sowie regelmäßigem Security-Audit absichern.

Public-Bastion oder internes Sprungbrett

Nicht jeder Jump-Host steht im Internet. Zwei Muster sind zu unterscheiden:

• Public-Bastion: steht in der DMZ und ist der einzige aus dem Internet erreichbare Host. Maximale Härtung ist Pflicht, weil er permanent gescannt wird.
• Internes Sprungbrett: ist selbst nicht öffentlich exponiert und nur über VPN oder Mesh erreichbar. Es trennt Zonen voneinander - klassisch OT von IT - und erzwingt, dass Wartungszugriffe einen kontrollierten Übergang nehmen. Hintergrund dazu in OT/IT-Segmentierung, DMZ und Fernwartung.

In sicheren Architekturen kombiniert man beides: kein direkter Internet-Zugang zum Sprungbrett, sondern erst ins Overlay-Netz, dann über ein internes, segmentierendes Sprungbrett zur Anlage.

Bastion oder Mesh-VPN: wann der Sprungserver bleibt

Ein Bastion ist simpel und wirksam, aber er bleibt ein öffentliches Ziel und ein Single Point of Failure. Moderne Zero-Trust-Mesh-VPNs wie NetBird verfolgen einen anderen Ansatz: Jeder Teilnehmer baut die Verbindung outbound-only auf, es gibt keinen offenen Inbound-Port, und der Zugriff ist identitätsbasiert und default-deny.

Bastion wählen, wenn Sie wenige Admins haben, klassisches SSH nutzen und ohne Client-Rollout ein minimales, gut verstandenes Setup wollen. Mesh-VPN/ZTNA wählen, wenn Sie viele verteilte Standorte ohne offene Ports anbinden, granularen Least-Privilege-Zugriff und einen sauberen, identitätsgebundenen Audit-Trail brauchen. NetBirds identity-aware SSH bildet Sitzungen direkt auf Nutzeridentitäten ab und beseitigt statischen Schlüsselwildwuchs. Häufig ist die Kombination ideal: das Mesh als Netz-Backend, darin ein internes Sprungbrett für die Segmentierung.

Schritt für Schritt: Grundkonfiguration

1. Sprungserver isolieren: eigene minimale VM/Container, Firewall erlaubt eingehend nur TCP 22 von definierten Quell-IPs. Zielsysteme ohne öffentliche IP.

2. sshd_config härten (auf dem Bastion):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowAgentForwarding no
X11Forwarding no
PermitTunnel no
AllowGroups ssh-jump
AuthenticationMethods publickey,keyboard-interactive

3. MFA aktivieren: ein PAM-TOTP-Modul (z. B. pam_google_authenticator) in die keyboard-interactive-Kette einbinden. Alternativ Anbindung an SSO/OIDC oder kurzlebige Zertifikate.

4. Client konfigurieren (~/.ssh/config auf der Workstation):

Host jump
    HostName jump.example.com
    User admin

Host internal-*
    ProxyJump jump
    User ops

Danach erreichen Sie interne Hosts direkt, etwa ssh internal-db01 - der Sprung über den Bastion passiert transparent, ohne Agent-Forwarding.

5. Logging zentralisieren: sshd-Logs an ein externes SIEM ausleiten, optional Session-Recording per auditd/tlog.

6. Optional: Zertifikate statt statischer authorized_keys über eine SSH-CA ausrollen.

Unser Vorgehen bei WZ-IT

Bei neuen, verteilten Umgebungen setzen wir selten auf einen klassischen, internetexponierten Bastion. Stattdessen binden wir Standorte outbound-only über ein identitätsbasiertes Mesh (NetBird) an und legen ein auditierbares Browser-Gateway darüber - kein offener SSH-Port nach außen. Wo ein interner Jump-Host als Segmentierungspunkt sinnvoll ist, härten wir ihn konsequent: Key-only, MFA, ProxyJump, eingeschränkte Shell und zentrales Logging. Wie das produktiv aussieht, zeigt die Case Study ABCO Water Systems für verteilte Anlagen in Australien. Konzeption, Aufbau und Betrieb übernehmen wir auf Wunsch komplett im Rahmen unserer Remote-Management-Plattformen.

Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Weiterführende Guides

• Was ist ZTNA? - das Zugriffsmodell jenseits des Choke-Points
• Was ist NetBird? - Mesh-VPN als Bastion-Ablösung
• OT/IT-Segmentierung, DMZ und Fernwartung
• SSO und MFA für Fernzugriff
• RBAC und Audit für Fernzugriff

Den richtigen Mix aus Bastion und Mesh planen? Lernen Sie uns kennen oder sehen Sie sich unsere Remote-Management-Plattformen an.