ssh Netzwerk-Durchsatzoptimieren

Die Geschwindigkeit von ssh wird von vielen Faktoren beeinflusst. LTSP verwendet zum Beispiel ssh um das X-Protokoll vom Terminalserver zum Client zu tunneln. Der Server ist üblicher Weise ein leistungsfähiges Gerät mit guter Netzanbindung (Gbit) und der Client ist sinnvoller Weise ein ThinClient, also ein leistungsschaches Gerät mit meistens billiger Hardware, die leider meistens mit ziemlich minderwertigen Komponenten wie zum Beispiel billigen Realtek Netzwerkcontrollern ausgerüstet sind (die man eigentlich nicht controller nennen dürfte...). Die Voreinstellungen von ssh sind auf gute Sicherheit abgestimmt, aber in einer ohnehin gesicherten Umgebung wie einem geschützten LAN kann man die Einstellungen mit Blick auf Durchsatz optimieren. Eine entscheidende Rolle spielt bei ssh der verwendete Algorithmus zur Verschlüsselung:


root@quellhost:~$ time scp -c [ALG] test-data.tar.gz root@zielhost:/dev/null

             real    user     sys
arcfour     2.628s  0.004s   0.060s
arcfour     3.899s  0.000s   0.036s (-o compression=yes)
blowfish    3.299s  0.008s   0.024s
aes128-cbc  3.048s  0.000s   0.024s
aes256-cbc  4.130s  0.000s   0.032s
3des-cbc    8.254s  0.004s   0.036s

Arcfour (RC4) ist zwar mit Sicherheitseinschränkungen bei known-plaintext-Angriff (Anfangskomplexität der Initialisierung nur 2^241) behaftet, bringt aber den besten Durchsatz. Bei Verwendung als Verschlüsselung des X-Protokolls ist ein known-plaintext-Angriff kein realistisches Szenario.

Hier im Test: scp einer komprimierten 18Mb Datei von einem Dual-Opteron 250 auf ein Pentium III, 333MHz. SSH kann auch den Datenstrom komprimieren, das erzeugt aber Sender- und Empfängerseitig deutlich mehr Rechenaufwand. Arcfour ist als einziger Alg ein Stromchiffreverfahren, alle anderen sind Blockchiffreverfahren. Ein Stromchiffre sollte Latenzvorteile haben. Bei Blockchiffre ist das Latenzverhalten komplizierter weil Latenzen vom Verhältnis Nutzdatenblockgrösse zu Chiffreblockgrösse abhängt. Arcfour ist auch auf sehr simplen Embedded-Prozessoren einfach und effizient zu implementieren. Auf Embedded-Systemen werden die Unterschiede mit schwächer werdenden Prozessoren noch etwas deutlicher:


(Thin Client mit VIA Nehemiah, 1GHz)
             real    user     sys
arcfour     2.450s  0.000s   0.040s
blowfish    3.105s  0.000s   0.028s
aes128-cbc  3.321s  0.004s   0.016s
aes256-cbc  4.310s  0.004s   0.016s

(Thin Client mit AMD Geode 500MHz)
             real    user     sys
arcfour     2.738s  0.000s   0.032s
arcfour     4.681s  0.004s   0.024s (-o compression=yes)
blowfish    4.469s  0.008s   0.036s
aes128-cbc  5.081s  0.000s   0.028s
aes256-cbc  7.265s  0.004s   0.020s
3des-cbc   12.128s  0.000s   0.040s

Andererseits verschwinden die Unterschiede wenn wie in diesem Test auf beiden Seiten sehr schnelle Maschinen mit Gbit eingesetzt werden:


             real    user     sys
arcfour     2.229s  0.180s   0.084s
blowfish    2.251s  0.308s   0.100s
3des-cbc    2.308s  0.968s   0.136s

Auf LTSP 5.0 angewendet lautet die Empfehlung also auf den Client-Images ssh wie folgt zu konfigurieren, es sei denn die LAN-Umgebung kann nicht wirklich als gesichert gelten:


    Ciphers arcfour
    Compression no

Je schwächer die ThinClients, desto wichtiger die richtige ssh Konfiguration. Was die Kompression angeht, muss man sagen, dass X-Datenströme von zum Beispiel schlanken Desktop-Themes und Office-Anwednungen sicher besser komprimieren als zum Beispiel der X-Datenstrom von Bildbearbeitungsfenstern oder gar Video. Für den LTSP Betrieb ist es sowieso empfehlenswert den X-Datenstrom nicht durch ssh zu schicken (LDM_DIRECTX=True in der /etc/lts.conf des Clients). Das reduziert die Prozessorlast deutlich, da für die reine Monitordarstellung nur Xorg und nicht ssh aktiv ist. Ohne diese Konfiguration erzeugt ssh oft eine grössere Prozessorlast als der Xorg Prozess. Das in ssh verwendete Kompressionsverfahren ist asymetrisch, Komprimieren ist mehr Rechenaufwand als dekomprimieren.. Das bedeutet dass mit steigender Anzahl an Clients die Kompression auch auf den LTSP Servern eine nicht unbeträchtliche Last erzeugt.