SSH beschleunigen: Verbindungs-Multiplexing für schnellere Sitzungen implementieren

SSH-Verbindungs-Multiplexing lässt wiederholte SSH-Befehle viel schneller erscheinen, da der zweite Befehl eine bestehende authentifizierte Verbindung wiederverwenden kann. Wenn Sie ssh host uptime ausführen, dann ssh host df -h und anschließend eine Datei per scp auf denselben Host kopieren, benötigt nur die erste Verbindung den vollständigen Handshake- und Authentifizierungsprozess.

Dies ist besonders nützlich für Administratoren, Entwickler und Automatisierungstools, die viele kurze Sitzungen öffnen. Es ist keine Magie und wird einen langsamen entfernten Befehl nicht schneller machen. Es beseitigt wiederholte Einrichtungskosten.

SSH-Verbindungs-Overhead verstehen

Jede standardmäßige SSH-Sitzung stellt standardmäßig eine brandneue TCP-Verbindung her und führt einen vollständigen Handshake durch. Dieser Prozess umfasst:

1. Schlüsselaustausch: Bestimmung der gemeinsamen Geheimnisse und kryptografischen Algorithmen.
2. Authentifizierung: Überprüfung der Benutzeranmeldeinformationen (Passwörter, Schlüsseldateien oder Zwei-Faktor-Token).
3. Sitzungseinrichtung: Initialisierung des Terminal- oder Befehlskanals.

Diese Einrichtungskosten sind in einem nahegelegenen LAN gering und bei Verbindungen mit hoher Latenz, VPNs, Bastion-Hosts oder Konten, die hardwaregestützte Schlüssel oder Multi-Faktor-Prompts erfordern, sehr deutlich spürbar. Verbindungs-Multiplexing vermeidet die Wiederholung eines Großteils dieser Arbeit, indem eine Master-Verbindung offen gehalten und neue Sitzungen durch diese geleitet werden.

Wie Multiplexing funktioniert

Verbindungs-Multiplexing verwendet einen lokalen Unix-Domain-Socket (eine Datei auf Ihrem lokalen Rechner), um zwischen dem Master-SSH-Prozess und allen neuen Slave-Prozessen zu kommunizieren.

• Die Master-Verbindung: Der erste von Ihnen ausgeführte SSH-Befehl erstellt die persistente Verbindung und richtet den Kommunikations-Socket ein.
• Der Control-Pfad: Der festgelegte lokale Dateipfad (der Socket), der von nachfolgenden Sitzungen verwendet wird, um nach dem Master zu suchen und sich mit ihm zu verbinden.
• Die wiederverwendete Verbindung: Jeder nachfolgende SSH-Befehl, der auf denselben effektiven Host, Benutzer und Port abzielt, verbindet sich über den lokalen Socket mit dem Master und vermeidet so eine vollständige neue SSH-Einrichtung.

Wichtige Konfigurationsdirektiven

Um Verbindungs-Multiplexing zu aktivieren, konfigurieren Sie Ihre SSH-Client-Einstellungen, typischerweise in der benutzerspezifischen Konfigurationsdatei (~/.ssh/config). Die drei kritischen Direktiven sind ControlMaster, ControlPath und ControlPersist.

1. ControlMaster

Diese Direktive gibt an, ob SSH versuchen soll, eine Master-Verbindung zu erstellen oder eine bestehende wiederzuverwenden.

Wert	Beschreibung
no	(Standard) Standardmäßiger Einzelverbindungsmodus.
yes	Erzwingt, dass die Sitzung zum Master wird und auf Slaves wartet. (Heute selten allein verwendet).
auto	Bevorzugte Einstellung. Wenn eine Master-Verbindung existiert, wird sie wiederverwendet; andernfalls wird eine neue Master-Verbindung initiiert.

Für die meisten Konfigurationen ist ControlMaster auto die praktische Standardeinstellung.

2. ControlPath

Der Pfad zur Unix-Domain-Socket-Datei, die für die Kommunikation verwendet wird. Dieser Pfad muss pro Remote-Host, Benutzer und Port-Kombination eindeutig sein, um zu verhindern, dass Sitzungen Steuerkanäle vermischen.

Die Verwendung von Variablen innerhalb des Pfads gewährleistet Eindeutigkeit:

Variable	Beschreibung
%r	Remote-Benutzername
%h	Remote-Hostname
%p	Remote-Port

Beispiel ControlPath:

ControlPath ~/.ssh/sockets/%r@%h:%p

Tipp: Erstellen Sie immer ein dediziertes Verzeichnis für diese Sockets (mkdir -p ~/.ssh/sockets) und stellen Sie sicher, dass es sichere Berechtigungen hat (chmod 700 ~/.ssh/sockets).

3. ControlPersist

Diese Direktive teilt der Master-Verbindung mit, wie lange sie nach Beendigung des anfänglichen Befehls offen bleiben soll.

Vor ControlPersist (eingeführt in OpenSSH 5.6) musste die Master-Verbindung an eine Terminalsitzung gebunden bleiben. Mit ControlPersist löst sich der Master-Prozess und bleibt im Hintergrund aktiv.

Wert	Beschreibung
no	Die Master-Verbindung wird sofort geschlossen, wenn das Terminal geschlossen wird.
yes	Die Master-Verbindung bleibt unbegrenzt bestehen (bis sie manuell geschlossen wird oder das System neu startet).
Zeitwerte	Gibt die Dauer an (z. B. 5m für 5 Minuten, 1h für 1 Stunde). Die Verbindung wird nach dieser Inaktivitätszeit geschlossen.

Die Einstellung ControlPersist 10m oder 15m ist ein vernünftiger Ausgangspunkt für typische Arbeitssitzungen. Verwenden Sie einen kürzeren Wert auf gemeinsam genutzten Workstations oder sensiblen Jump-Hosts.

Praktische Implementierung in ~/.ssh/config

Nachfolgend finden Sie Beispiele, die zeigen, wie Sie Multiplexing in Ihrer SSH-Client-Konfigurationsdatei konfigurieren.

Beispiel 1: Globale Konfiguration

Diese Konfiguration wendet Verbindungs-Multiplexing auf alle Remote-Hosts an, mit denen Sie eine Verbindung herstellen, vorausgesetzt, sie laufen auf dem Standard-Port 22.

# Konfiguration für ALLE Hosts (*)
Host *
    # Wiederverwendung oder Initiierung der Verbindung aktivieren
    ControlMaster auto

    # Verbindung 15 Minuten nach Schließen der letzten Sitzung am Leben halten
    ControlPersist 15m

    # Socket-Pfad definieren, der Eindeutigkeit basierend auf Benutzer, Host und Port gewährleistet
    ControlPath ~/.ssh/sockets/%r@%h:%p

    # Optional: nützlich bei einigen Verbindungen mit geringer Bandbreite, aber nicht immer schneller
    Compression yes

Beispiel 2: Host-spezifische Konfiguration

Es ist oft besser, Multiplexing auf häufig besuchte Hosts oder Gruppen zu beschränken.

# Konfiguration spezifisch für Hosts, die auf 'prod-*' passen
Host prod-*
    HostName %h.example.com
    ControlMaster auto
    ControlPersist 5m
    ControlPath ~/.ssh/sockets/%r@%h:%p

# Konfiguration spezifisch für den Jump-Host (der möglicherweise eine längere Persistenz erfordert)
Host jumpbox
    ControlMaster auto
    ControlPersist 1h
    ControlPath ~/.ssh/sockets/%r@%h:%p

Nutzung, Überprüfung und Verwaltung

1. Überprüfung der Geschwindigkeitsverbesserung

Sie können die Leistungssteigerungen mit dem Befehl time einfach überprüfen.

Erste Verbindung:

$ time ssh myhost exit

real    0m1.234s
user    0m0.045s
sys     0m0.015s

Nachfolgende Verbindung, während der Master aktiv ist:

$ time ssh myhost exit

real    0m0.045s
user    0m0.005s
sys     0m0.003s

2. Überprüfung des Master-Verbindungsstatus

Sobald eine Master-Verbindung hergestellt ist, existiert die Socket-Datei in Ihrem angegebenen ControlPath. Sie können den Status der Verbindung mit dem Flag -O (Control-Option) überprüfen.

# Überprüfen, ob die Verbindung zu myhost aktiv ist
ssh -O check myhost

Bei Erfolg bestätigt die Ausgabe, dass die Socket-Verbindung geöffnet ist.

3. Beenden der Master-Verbindung

Wenn Sie die persistente Master-Verbindung sofort schließen müssen (z. B. weil sich Authentifizierungsdaten geändert haben oder Sie eine neue Konfiguration testen möchten), verwenden Sie die Control-Option exit:

# Beendet die Master-Verbindung zu myhost
ssh -O exit myhost

Dieser Befehl weist den Master-Prozess an, sich ordnungsgemäß herunterzufahren. Nachfolgende Sitzungen werden dann gezwungen, eine neue Master-Verbindung zu erstellen.

Eine sicherere Standardkonfiguration

Bei neueren OpenSSH-Clients ist %C oft ein besserer ControlPath-Token als die manuelle Kombination von %r, %h und %p. Es wird zu einem Hash der Verbindungsdetails erweitert, was lange Unix-Socket-Pfade und umständliche Zeichen in Hostnamen vermeidet.

Host *
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/sockets/%C

Die Länge des Socket-Pfads ist wichtig, da Unix-Domain-Sockets plattformspezifische Grenzen haben. Ein langer Pfad wie ~/.ssh/sockets/[email protected]:2222 kann auf einigen Systemen fehlschlagen. Wenn Sie Fehler sehen, dass der Control-Pfad zu lang ist, wechseln Sie zu %C.

Stellen Sie außerdem sicher, dass das Socket-Verzeichnis existiert, bevor Sie sich auf diese Konfiguration verlassen:

mkdir -p ~/.ssh/sockets
chmod 700 ~/.ssh/sockets

Wann Multiplexing vermieden werden sollte

Aktivieren Sie Multiplexing nicht blind für jede Situation. Einige Fälle erfordern Vorsicht:

• Ändernde Kontoberechtigungen: Wenn sich Gruppenmitgliedschaften, erzwungene Befehle oder serverseitige Kontorichtlinien während einer Sitzung ändern, spiegelt eine wiederverwendete Verbindung möglicherweise nicht den neuen Zustand wider, bis der Master geschlossen wird.
• Fehlerbehebung bei Bastion- und Jump-Hosts: Deaktivieren Sie beim Testen von Verbindungsfehlern das Multiplexing, damit Sie wissen, dass jeder Befehl einen neuen Pfad erstellt.
• Hochsensible Hosts: Eine persistente Master-Verbindung hält einen authentifizierten Kanal von Ihrem lokalen Konto aus verfügbar, bis ControlPersist abläuft. Das ist auf einem persönlichen Arbeitsplatz mit korrekten Berechtigungen normalerweise in Ordnung, passt aber möglicherweise nicht zu jeder Sicherheitsrichtlinie.

Für einen einzelnen Befehl deaktivieren Sie die Wiederverwendung wie folgt:

ssh -o ControlMaster=no -o ControlPath=none user@host

Multiplexing mit Automatisierungstools

Ansible, rsync, Git über SSH und Bereitstellungsskripte können alle von Multiplexing profitieren, da sie oft viele kurze Sitzungen öffnen. Für Ansible leben die SSH-Argumente normalerweise in ansible.cfg:

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=10m -o ControlPath=~/.ssh/sockets/%C

Wenn Ihre Automatisierung von CI aus läuft, denken Sie über den Lebenszyklus des Runners nach. Ein kurzlebiger CI-Job profitiert möglicherweise nicht viel, da der Arbeitsbereich nach dem Job verschwindet. Ein langlebiger Bereitstellungshost kann stark profitieren, benötigt aber auch Bereinigung und vorhersagbare Berechtigungen. Legen Sie Steuer-Sockets nicht in ein gemeinsames, weltweit beschreibbares Verzeichnis wie /tmp, es sei denn, Sie verstehen die Sicherheitsauswirkungen vollständig und verwenden ein privates Unterverzeichnis.

Für rsync hilft Multiplexing am meisten, wenn Ihr Workflow mehrere separate rsync- oder ssh-Befehle gegen denselben Host ausführt:

rsync -az ./release/ app@web01:/opt/app/releases/current/
ssh app@web01 'systemctl --user restart app'
ssh app@web01 'systemctl --user status app --no-pager'

Der erste Befehl öffnet den Master. Die nächsten beiden können ihn wiederverwenden, wenn Host, Benutzer, Port und die effektiven SSH-Optionen übereinstimmen.

Fehlerbehebung bei veralteten Socket-Problemen

Manchmal bleibt eine Socket-Datei zurück, nachdem die Master-Verbindung beendet wurde. Wenn das passiert, kann ein späterer SSH-Befehl einen Fehler bezüglich der Verbindung zum Control-Socket ausgeben und dann auf eine normale Verbindung zurückfallen, oder er kann je nach verwendeten Optionen fehlschlagen.

Überprüfen Sie zuerst den Master:

ssh -O check web01

Wenn dies fehlschlägt und Sie einen alten Socket unter ~/.ssh/sockets sehen können, entfernen Sie diese veraltete Datei. Wenn dies häufig vorkommt, überprüfen Sie, ob Ihr Arbeitsplatz in den Ruhezustand versetzt wird, die VPN-Verbindung getrennt wird oder Netzwerkänderungen die Master-Verbindung beenden. Ein kürzeres ControlPersist kann bei instabilen Netzwerken besser sein als ein langlebiger Master.

Sie können SSH auch bitten, beim Debuggen expliziter zu sein:

ssh -vvv web01 exit

Achten Sie auf Zeilen, die ControlPath, mux_client oder einen vorhandenen Master erwähnen. Sobald Sie wissen, dass Multiplexing beteiligt ist, schließen Sie den Master und testen Sie erneut, bevor Sie DNS, Schlüssel oder den entfernten SSH-Daemon beschuldigen.

Jump-Hosts und Optionsabgleich

Multiplexing ist an das effektive SSH-Ziel und die Optionen gebunden. Wenn Sie sich einmal direkt und einmal über einen Jump-Host mit demselben Server verbinden, sind dies nicht unbedingt dieselbe Steuerverbindung. Gleiches gilt, wenn ein Befehl einen Host-Alias verwendet und ein anderer Befehl den rohen Hostnamen mit anderen User-, Port-, ProxyJump- oder Identitätsdatei-Einstellungen verwendet.

Für eine vorhersagbare Wiederverwendung setzen Sie die tatsächlichen Verbindungsdetails in ~/.ssh/config und verwenden Sie den Alias überall:

Host app-prod-1
    HostName 10.20.30.41
    User deploy
    ProxyJump bastion-prod
    IdentityFile ~/.ssh/prod_deploy
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/sockets/%C

Führen Sie dann ssh app-prod-1, scp file app-prod-1:/tmp/ und Automatisierung gegen app-prod-1 aus. Das Mischen von Aliasen, IP-Adressen und einmaligen -J-Flags macht es schwieriger zu verstehen, ob ein Befehl den vorhandenen Master wiederverwenden sollte.

Aus diesem Grund sollten Teams die bevorzugten Host-Aliase in Runbooks dokumentieren. Eine gemeinsame Konvention verhindert verwirrende halbwiederverwendete Verbindungen während Bereitstellungen.

Fehlerbehebung und Best Practices

Verzeichnis und Berechtigungen

Sicherheit ist von größter Bedeutung. Die von SSH erstellte Socket-Datei enthält Metadaten über Ihre Verbindung, einschließlich potenzieller Steuerbefehle. Stellen Sie sicher, dass das Socket-Verzeichnis eingeschränkte Berechtigungen hat.

# Erstellen Sie das Verzeichnis, falls es nicht existiert
mkdir -p ~/.ssh/sockets

# Setzen Sie strenge Berechtigungen (nur für den Besitzer zugänglich)
chmod 700 ~/.ssh/sockets

Steuerung mehrerer Benutzer

Wenn Sie verschiedene Benutzernamen verwenden, um eine Verbindung zum selben Host herzustellen, behandelt Multiplexing dies automatisch, da die Variable %r (Remote-Benutzer) im ControlPath sicherstellt, dass separate Sockets für user1@host und user2@host erstellt werden.

Konflikte mit anderen Clients

Wenn Sie automatisierte Skripte oder Tools ausführen, die auf SSH angewiesen sind, stellen Sie sicher, dass diese entweder dieselben Multiplexing-Einstellungen verwenden oder diese bei Bedarf explizit deaktivieren. Wenn ein Skript eine neue Verbindung sicherstellen muss, können Sie das Nicht-Multiplexing-Verhalten in der Befehlszeile erzwingen:

ssh -o ControlMaster=no user@host

SSH-Verbindungs-Multiplexing ist eine der einfachsten Verbesserungen der Lebensqualität bei häufiger SSH-Nutzung. Konfigurieren Sie ControlMaster auto, verwenden Sie einen eindeutigen und kurzen ControlPath, setzen Sie ein angemessenes ControlPersist und überprüfen Sie mit ssh -O check host. Wenn sich eine Verbindung während der Fehlerbehebung seltsam verhält, schließen Sie den Master mit ssh -O exit host und testen Sie erneut mit einer neuen Sitzung.