- In einer SSH-Sitzung wurde beobachtet, dass bei einem einzelnen Tastendruck Hunderte von Paketen übertragen werden; der Fall wurde bis zur Ursache zurückverfolgt
- Die Analyse mit
tcpdump zeigte, dass die meisten Pakete aus sich wiederholenden 36-Byte-Nachrichten bestanden und in Abständen von etwa 20 ms auftraten
- Ursache war die 2023 zu SSH hinzugefügte Funktion zur Verschleierung des Tastenanschlag-Timings (keystroke timing obfuscation), die zur Verbergung des Eingabe-Timings des Nutzers zahlreiche „chaff“-Pakete (SSH2_MSG_PING) sendet
- Wird diese Funktion deaktiviert oder der Server so geändert, dass er die Erweiterung
[email protected] nicht bewirbt, sinken CPU-Auslastung und Bandbreitenverbrauch auf weniger als die Hälfte
- Der Fall zeigt, dass eine Sicherheitsfunktion von SSH bei Anwendungen mit kritischer Echtzeit-Performance (z. B. Spiele) zu erheblicher Last führen kann
Problem entdeckt
- Beim Testen der TUI eines Hochleistungsspiels, das über SSH ausgeführt wird, wurde festgestellt, dass bereits ein einzelner Tastendruck 270 Pakete auslöste
- Laut
tcpdump waren 66 % davon 36-Byte-Nachrichten, 33 % TCP-ACKs und der Rest kleine Mengen sonstiger Daten
- Im Durchschnitt wurden 90 Pakete/Sekunde mit einem Abstand von etwa 11 ms übertragen
- Während der Tests war der Server fälschlich so konfiguriert, dass er nur die Meldung „your screen is too small“ sendete; dabei halbierten sich CPU- und Bandbreitennutzung
- Obwohl keine Spieldaten übertragen werden sollten und die CPU-Auslastung nahe 0 % liegen müsste, blieb sie dennoch bei etwa 50 %
- Dadurch entstand der Verdacht, dass SSH selbst Kommunikations-Overhead verursacht
Untersuchungsverlauf
- Mit
tcpdump wurde der SSH-Verkehr im Normalbetrieb und im Fehlerzustand verglichen
- Auch im Fehlerzustand traten die 36-Byte-Pakete weiterhin alle 20 ms auf
- Dasselbe Muster wurde auch mit dem standardmäßigen SSH-Client von macOS bestätigt
- Die Analyse der pcap-Dateien mit Claude Code ergab
- Von insgesamt 413.703 Paketen waren 66 % 36 Byte groß, 34 % waren 0-Byte-ACKs
- Der SSH-Client erzeugte die Pakete aktiv
Grundursache
Lösungsansätze
- Auf Client-Seite kann die Funktion mit der Option
ObscureKeystrokeTiming=no deaktiviert werden
- Danach sanken CPU-Auslastung und Bandbreitenverbrauch deutlich, während die Datenübertragung normal erhalten blieb
- Als serverseitige Maßnahme wurde in Gos SSH-Bibliothek die Bewerbung der Erweiterung
[email protected] entfernt
- Nach dem Rückgängigmachen des entsprechenden Commits ergaben Tests
- CPU-Auslastung 29,9 % → 11,6 %,
Systemaufrufe 3,10 s → 0,66 s,
Kryptoberechnungen 1,6 s → 0,11 s,
Bandbreite 6,5 Mbit/s → 3 Mbit/s
- Die Performance verbesserte sich um mehr als 50 %
Debugging-Erfahrungen mit LLMs
- Mit Claude Code wurde die Analyse von
tcpdump und tshark automatisiert, wodurch sich die Ursache schnell eingrenzen ließ
- Durch das Echtzeit-Beobachten der Befehlsausführung ließ sich ein mentales Modell des Problems aufrechterhalten
- Mit ChatGPT wurde auch ein Unterschied zwischen den Modellen erlebt, etwa als das Verhalten von SSH fälschlich als „normal“ eingestuft wurde
- LLMs ersetzen zwar nicht den gesamten Problemlösungsprozess, zeigen aber als unterstützende Analysewerkzeuge eine hohe Effizienz
- Ein Beispiel dafür, wie sich menschliches Schlussfolgern und LLM-Analyse kombinieren lassen, um komplexe Netzwerk-Performance-Probleme zu lösen
Noch keine Kommentare.