Sprungserver: eine Tür statt zwanzig

Fünf Maschinen, fünf offene SSH-Ports, fünf Regelwerke, fünfmal authorized_keys pflegen. Ein Sprungserver reduziert das auf einen erreichbaren Port und macht nebenbei die Frage „wer war wann drauf?“ beantwortbar.

Der Weg dahin, ohne Agent-Weiterleitung#

Der verbreitete Ansatz ist ssh -A, den eigenen Agenten auf den Sprungserver durchreichen. Das funktioniert und hat einen Haken: Wer auf dem Sprungserver root ist, kann den weitergereichten Agenten für eigene Verbindungen benutzen, solange die Sitzung offen ist.

ProxyJump löst dasselbe Problem ohne diesen Haken. Der Sprungserver leitet nur die verschlüsselte Verbindung weiter; die Authentifizierung findet zwischen deinem Rechner und dem Ziel statt.

# ~/.ssh/config auf deinem Rechner
Host bastion
    HostName 203.0.113.10
    User mauri
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host web01 db01 mon01
    HostName %h.intern.example
    User mauri
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

ssh db01          # springt automatisch über bastion
scp datei.tar.gz db01:/tmp/

Für ForwardAgent gibt es damit keinen Grund mehr. In der Client-Konfiguration bleibt es aus:

Host *
    ForwardAgent no

Der Sprungserver selbst#

Er ist die einzige von außen erreichbare Maschine, entsprechend wenig sollte darauf laufen.

# /etc/ssh/sshd_config.d/10-bastion.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers mauri kollegin

# Der Sprungserver ist Durchgang, kein Arbeitsplatz.
AllowTcpForwarding yes
PermitOpen 10.20.0.0/24:22
X11Forwarding no
AllowAgentForwarding no

ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
MaxSessions 4

PermitOpen ist die Zeile, die den Unterschied macht: Der Sprungserver darf Verbindungen nur ins interne Netz auf Port 22 weiterleiten. Ohne sie ist er ein offener Weiterleitungsdienst für alles, was der angemeldete Benutzer sich ausdenkt.

Auf den internen Maschinen dann die Gegenseite:

# Nur vom Sprungserver aus erreichbar
Match Address 10.20.0.5
    PermitRootLogin no

# Firewall auf den internen Maschinen
tcp dport 22 ip saddr 10.20.0.5 accept
tcp dport 22 drop

Was auf dem Sprungserver nicht hingehört#

• Keine Dienste außer SSH. Kein Webserver, kein Monitoring-Agent mit offenem Port, keine Datenbank.
• Keine Daten. Keine Schlüssel für andere Systeme, keine Zugangsdaten, keine Backups. Wer ihn übernimmt, soll nichts finden.
• Keine Nutzer-Home-Verzeichnisse als Ablage. /home ist Durchgang.

Protokollieren, damit es etwas bringt#

Der Sprungserver ist die Stelle, an der jeder Zugang vorbeikommt, entsprechend wertvoll sind seine Protokolle. Und entsprechend wichtig ist, dass sie ihn verlassen:

sudo journalctl -u ssh --since today | grep -E 'Accepted|session opened'

Wie das zentrale Wegschicken aussieht, steht in Protokolle, die den Angreifer überleben. Auf dem Sprungserver ist es kein Komfort, sondern der Kern seines Nutzens.

Wann ein VPN die bessere Antwort ist#

Ein Sprungserver löst SSH-Zugang. Ein VPN (WireGuard, Tailscale, NetBird) löst allen Zugang, auch Verwaltungsoberflächen, Metrik-Endpunkte und Datenbank-Clients.

In kleinen Umgebungen mit drei bis zehn Maschinen und mehreren Verwaltungsoberflächen ist ein Overlay-Netz meist die praktischere Wahl, dann binden die Dienste auf die VPN-Adresse statt auf 0.0.0.0, und die Firewall wird kürzer. Das Prinzip dahinter ist dasselbe wie in Eingehend dichtmachen: Was nicht nach außen hört, braucht keine Regel.