Der vollständige Leitfaden zur Optimierung der SSH-Leistung mit ZLib-Kompression

Secure Shell (SSH) ist zuverlässig, aber die SSH-Leistung kann sich auf langsamen WAN-Verbindungen, VPNs oder bei umfangreichen Terminalsitzungen schlecht anfühlen. Zlib-Kompression kann helfen, wenn die Daten textlastig sind und das Netzwerk der Engpass ist, aber sie kann CPU verschwenden, wenn die Verbindung bereits schnell ist oder die Dateien bereits komprimiert sind.

Dieser Leitfaden erklärt, wo SSH-Kompression sinnvoll ist, wie Sie sie auf Client und Server aktivieren und wie Sie testen, ob sie Ihre Arbeitslast tatsächlich verbessert.

SSH-Leistung und Kompression verstehen

Die SSH-Leistung kann durch verschiedene Faktoren beeinflusst werden, darunter Netzwerklatenz, verfügbare Bandbreite und die Art der übertragenen Daten. Beispielsweise kann die Übertragung großer Textdateien, Log-Archive oder die Interaktion mit einer ausführlichen Befehlszeilenanwendung über eine langsame Verbindung träge wirken. Hier kommt die Kompression ins Spiel.

ZLib-Kompression ist eine weit verbreitete Datenkompressionsbibliothek, die ein gutes Gleichgewicht zwischen Kompressionsrate und Geschwindigkeit bietet. Wenn sie in SSH integriert ist, komprimiert ZLib Daten, bevor sie verschlüsselt und über das Netzwerk gesendet werden, und dekomprimiert sie beim Empfang. Dies reduziert die Gesamtmenge der übertragenen Daten, was potenziell zu schnelleren Übertragungen und einem reaktionsschnelleren Erlebnis führt.

Wie ZLib mit SSH funktioniert

Wenn SSH-Kompression aktiviert ist, handeln Client und Server die Verwendung von ZLib aus. Sobald dies eingerichtet ist, werden alle Datennutzlasten (z. B. Shell-Ausgabe, Dateiinhalte während scp/sftp) vom Sender komprimiert und vom Empfänger dekomprimiert. Der eigentliche SSH-Protokoll-Overhead wie Header und Verschlüsselungsschlüssel wird in der Regel nicht komprimiert. Die Option Compression in SSH-Clients und -Servern bezieht sich normalerweise auf die ZLib-Kompression.

Wann SSH-Kompression verwendet werden sollte (und wann nicht)

Die Aktivierung der Kompression ist keine universelle Lösung; ihre Vorteile hängen stark von Ihrem spezifischen Anwendungsfall und den Netzwerkbedingungen ab. Zu verstehen, wann sie anzuwenden ist, ist der Schlüssel zur echten Optimierung.

Ideale Szenarien für SSH-Kompression

Niedrige Bandbreitenverbindungen: Wenn Ihre Netzwerkverbindung nur über begrenzte Bandbreite verfügt (z. B. DSL, Satelliteninternet oder überlastetes WLAN), kann die Reduzierung der übertragenen Datenmenge den effektiven Durchsatz erheblich verbessern. Die Zeitersparnis durch weniger Datenübertragung überwiegt die CPU-Zyklen, die für Kompression/Dekomprimierung aufgewendet werden.
Hochlatenzverbindungen: Selbst bei ausreichender Bandbreite kann eine hohe Latenz interaktive SSH-Sitzungen träge erscheinen lassen. Kompression kann einen großen Unterschied machen, indem sie sicherstellt, dass Daten, wenn sie doch übertragen werden, so kompakt wie möglich sind, was die "Zeit bis zum ersten Byte" für große Ausgaben reduziert.
Übertragung stark repetitiver Daten: Textdateien, Logdateien, Konfigurationsdateien, Quellcode und andere Formen strukturierter oder halbstrukturierter Daten enthalten oft ein hohes Maß an Redundanz. ZLib ist sehr effektiv bei der Komprimierung solcher Daten, was zu erheblichen Größenreduzierungen führt.
Interaktive Terminalsitzungen mit ausführlicher Ausgabe: Wenn Sie häufig Befehle ausführen, die umfangreiche Textausgaben produzieren (z. B. dmesg, journalctl, git log in einem großen Repository), kann die Kompression dafür sorgen, dass diese Ausgaben in Ihrem Terminal viel schneller erscheinen.

Wann SSH-Kompression vermieden oder mit Vorsicht verwendet werden sollte

Hochbandbreiten-, Niedriglatenz-LAN-Verbindungen: In schnellen lokalen Netzwerken kann der Overhead durch Komprimieren und Dekomprimieren von Daten mehr CPU-Zyklen verbrauchen als die Zeitersparnis durch reduzierte Datenübertragung. In solchen Fällen ist der Netzwerk-Link wahrscheinlich nicht der Engpass, und die CPU-Auslastung wird zum limitierenden Faktor.
Übertragung bereits komprimierter Daten: Der Versuch, Dateien zu komprimieren, die bereits komprimiert sind (z. B. JPEG-Bilder, MP3-Audio, ZIP-Archive, GZip-Dateien, MP4-Videos), ist weitgehend wirkungslos. ZLib wird wenig bis keine weitere Redundanz finden, was zu einer vernachlässigbaren Größenreduzierung führt und lediglich unnötigen CPU-Overhead verursacht.
CPU-gebundene Systeme (Client oder Server): Wenn entweder Ihr Client-Rechner oder der SSH-Server bereits stark ausgelastet ist, kann die Aktivierung der Kompression Leistungsprobleme verschlimmern statt lösen. Überwachen Sie die CPU-Auslastung, um sicherzustellen, dass die Kompression keine zusätzliche Belastung darstellt.

Aktivieren der ZLib-Kompression in SSH

SSH-Kompression kann clientseitig, serverseitig oder über Konfigurationsdateien für dauerhafte Einstellungen aktiviert werden.

Clientseitige Konfiguration

Normalerweise steuern Sie die Kompression von Ihrem lokalen Rechner (dem SSH-Client).

1. Verwendung der `-C` Befehlszeilenoption

Der einfachste Weg, die Kompression für einen einzelnen SSH-Befehl zu aktivieren, ist die Verwendung des -C Flags:

ssh -C benutzer@hostname
scp -C lokale_datei benutzer@hostname:/remote/pfad
sftp -C benutzer@hostname

Diese Option erzwingt die Kompression für die spezifische Sitzung, die durch diesen Befehl initiiert wird. Sie ist nützlich zum Testen oder für einmalige Übertragungen, bei denen Sie wissen, dass die Kompression vorteilhaft ist.

2. Verwendung der `~/.ssh/config` Datei

Für eine dauerhafte Kompression für bestimmte Hosts oder alle Hosts können Sie Ihre SSH-Client-Konfigurationsdatei bearbeiten, die sich normalerweise unter ~/.ssh/config auf Unix-ähnlichen Systemen befindet. Wenn die Datei nicht existiert, können Sie sie erstellen.

# Kompression für alle Hosts standardmäßig aktivieren
Host *
    Compression yes

# Kompression nur für einen bestimmten Host aktivieren
Host mein_entfernter_server
    HostName 192.168.1.100
    User entfernter_benutzer
    Compression yes
    Port 2222

# Kompression für einen bestimmten Host deaktivieren (überschreibt globale Einstellung)
Host schneller_lan_server
    HostName 10.0.0.5
    Compression no

Erklärung der Direktiven:

Host *: Wendet die folgenden Einstellungen auf alle SSH-Verbindungen an, es sei denn, sie werden durch einen spezifischeren Host-Block überschrieben.
Host mein_entfernter_server: Wendet Einstellungen nur an, wenn Sie sich mit ssh mein_entfernter_server verbinden.
Compression yes|no: Aktiviert oder deaktiviert explizit die Kompression für den angegebenen Host oder global.

Serverseitige Konfiguration (optional, aber zur Kontrolle empfohlen)

Während die clientseitige Aktivierung im Allgemeinen ausreicht, damit die Kompression ausgehandelt wird (wenn der Server sie unterstützt), hat der SSH-Server (sshd) auch Konfigurationsoptionen in Bezug auf die Kompression. Diese befinden sich normalerweise in /etc/ssh/sshd_config.

1. Die `Compression` Direktive

Standardmäßig erlaubt sshd normalerweise die Kompression, wenn sie vom Client angefordert wird. Sie können sie jedoch explizit festlegen:

# /etc/ssh/sshd_config
Compression yes

Das Setzen von Compression yes auf dem Server erlaubt es dem Server, Kompressionsanfragen von Clients zu akzeptieren und zu verarbeiten. Das Setzen auf no deaktiviert die Kompression, selbst wenn der Client sie anfordert.

2. Die `Compression` Direktive mit `delayed`

Für eine optimale Serverleistung, insbesondere bei vielen gleichzeitigen Verbindungen, hat OpenSSH die Option Compression delayed eingeführt. Diese Einstellung verzögert den Start der Kompression, bis sich der Benutzer erfolgreich authentifiziert hat. Dies verhindert, dass unnötige CPU-Zyklen für die Komprimierung von Authentifizierungsversuchen (die normalerweise klein und nicht repetitiv sind) von potenziell bösartigen oder Bot-Clients aufgewendet werden.

# /etc/ssh/sshd_config
Compression delayed

Nachdem Sie /etc/ssh/sshd_config geändert haben, validieren Sie die Datei und laden Sie sshd neu oder starten Sie es neu:

sudo sshd -t
sudo systemctl reload sshd

Einige Distributionen nennen den Dienst ssh anstelle von sshd, insbesondere Debian-basierte Systeme.

Praktische Beispiele und Anwendungsfälle

Schauen wir uns an, wie sich die Kompression in realen Vorteilen niederschlägt.

Beispiel 1: Übertragen großer Logdateien mit `scp`

Angenommen, Sie müssen eine mehrere Gigabyte große Logdatei von einem entfernten Server über eine relativ langsame Verbindung herunterladen. Die Logdatei (application.log) enthält hochrepetitive Textdaten.

Ohne Kompression:

time scp benutzer@entfernter_host:/var/log/application.log .

Mit Kompression:

time scp -C benutzer@entfernter_host:/var/log/application.log .

Durch das Hinzufügen von -C verwendet der scp-Befehl die Kompression. Sie werden wahrscheinlich eine deutliche Reduzierung der Übertragungszeit feststellen, insbesondere wenn sich die Logdatei gut komprimieren lässt.

Beispiel 2: Verbesserung der `rsync`-Leistung über SSH

rsync kann Dateidaten selbst mit -z komprimieren oder SSH-Kompression über ssh -C verwenden. Normalerweise sollten Sie eine auswählen und testen, anstatt beide zu stapeln.

rsync -avz /lokaler/pfad/zum/sync benutzer@entfernter_host:/entferntes/ziel/

rsync -av -e "ssh -C" /lokaler/pfad/zum/sync benutzer@entfernter_host:/entferntes/ziel/

-a: Archivmodus (bewahrt Berechtigungen, Zeitstempel usw.)
-v: Ausführliche Ausgabe
-z: rsyncs eigene Kompression. Diese ist oft ausreichend für Dateiübertragungen über langsame Verbindungen.
-e "ssh -C": Gibt ssh -C als entfernte Shell an.

Beispiel 3: Verbesserung der Reaktionsfähigkeit der interaktiven Shell

Wenn Sie Befehle wie ls -lR / auf einem großen Dateisystem ausführen oder ausführliche Diagnoseausgaben abrufen, kann die Kompression die Verzögerung reduzieren, bis die Ausgabe zu erscheinen beginnt und fertig gedruckt ist.

ssh -C benutzer@hostname "ls -lR /"

Dadurch wird das interaktive Erlebnis im Vergleich zu einer nicht komprimierten Sitzung bei einer schlechten Netzwerkverbindung viel flotter wirken.

Messen der Auswirkungen der Kompression

Um die Vorteile wirklich zu verstehen, müssen Sie die Leistung vorher und nachher messen. Tools wie time (wie in den Beispielen gezeigt) können die Gesamtausführungszeit messen. Für den Netzwerkdurchsatz können Sie iperf3 verwenden (obwohl dies die rohe Netzwerkgeschwindigkeit misst, nicht den SSH-Overhead). Der direkteste Weg ist, die tatsächlichen Dateiübertragungszeiten zu vergleichen und die Reaktionsfähigkeit interaktiver Sitzungen zu beobachten.

Sie können auch ssh -v verwenden, um ausführliche Debugging-Ausgaben zu sehen, die gelegentlich die Kompressionsnutzung anzeigen können, aber direkte Leistungsmessungen sind aussagekräftiger.

Best Practices und fortgeschrittene Tipps

In Ihrer Umgebung testen: Testen Sie die Kompression immer mit Ihren spezifischen Netzwerkbedingungen und Datentypen. Was für ein Szenario gut funktioniert, kann für ein anderes nachteilig sein.
CPU-Auslastung überwachen: Überprüfen Sie bei schweren Übertragungen oder längeren interaktiven Sitzungen mit aktivierter Kompression die CPU-Last sowohl auf dem Client als auch auf dem Server. Wenn die CPU-Auslastung übermäßig ansteigt, könnte die Kompression kontraproduktiv sein.
Mit anderen Optimierungen kombinieren: Kompression ist nur ein Aspekt der SSH-Optimierung. Erwägen Sie die Kombination mit:
- Verbindungsmultiplexing: Wiederverwendung bestehender SSH-Verbindungen (ControlMaster, ControlPath in ~/.ssh/config), um wiederholten Handshake-Overhead zu vermeiden.
- Cipher-Auswahl: Auswahl schnellerer Cipher (z. B. [email protected], [email protected]), wenn es die Sicherheitsanforderungen erlauben, da einige Cipher weniger CPU-intensiv sind als andere.
- KeepAlive-Einstellungen: Verwendung von ServerAliveInterval und ClientAliveInterval, um zu verhindern, dass Verbindungen aufgrund von Inaktivität abbrechen.
Seien Sie spezifisch mit der Konfiguration: Anstatt Compression yes global in ~/.ssh/config zu aktivieren, verwenden Sie Host-Blöcke, um es nur auf Hosts anzuwenden, bei denen Sie wissen, dass es vorteilhaft ist.

Fazit

Verwenden Sie SSH-Zlib-Kompression für langsame Verbindungen, Terminalsitzungen mit viel Textausgabe und Übertragungen von Klartext wie Logs oder Quelltextbäumen. Lassen Sie sie für schnelle LANs, CPU-gebundene Hosts und bereits komprimierte Dateien ausgeschaltet. Der sicherste nächste Schritt ist, denselben Befehl mit und ohne -C zu testen, die CPU-Auslastung zu beobachten und dann Compression yes nur für die Hosts zu aktivieren, bei denen die Messung eindeutig besser ist.