Skip to content

Cipher-Wahl für SSH-Kopieraktionen ...

Durch die geschickte Wahl der Cipher Suite bei Kopieraktionen über die SSH kann man sehr viel Transferzeit sparen.

Ich habe das einmal mit einem kleinen Skript getestet. Der Test wurde in einem 100 MBit/s-Netz gemacht. Sender und Empfänger hingen am gleichen Switch.
#!/bin/bash

for cipher in 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr arcfour128 arcfour256 arcfour blowfish-cbc cast128-cbc
do
    echo ${cipher}
    for i in {1..3}
    do
        scp -c ${cipher} stardust-lan:/srv/iso/ubuntu-10.04.1-server-i386.iso .
        rm *.iso
    done
    echo
done

Das führte zu diesem Resultat, die Kopieraktion, bei der der mittlere Wert am besten ist, habe ich fett markiert:

3des-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 7.0MB/s 01:36
ubuntu-10.04.1-server-i386.iso 100% 672MB 6.7MB/s 01:41
ubuntu-10.04.1-server-i386.iso 100% 672MB 6.7MB/s 01:40

aes128-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.0MB/s 01:24
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.0MB/s 01:24
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.0MB/s 01:24

aes192-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.0MB/s 01:24
ubuntu-10.04.1-server-i386.iso 100% 672MB 7.6MB/s 01:29
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.3MB/s 01:21

aes256-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 11.0MB/s 01:01
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.9MB/s 01:08
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.3MB/s 01:05

aes128-ctr
ubuntu-10.04.1-server-i386.iso 100% 672MB 7.9MB/s 01:25
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.1MB/s 01:23
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.1MB/s 01:23

aes192-ctr
ubuntu-10.04.1-server-i386.iso 100% 672MB 11.0MB/s 01:01
ubuntu-10.04.1-server-i386.iso 100% 672MB 11.2MB/s 01:00
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.7MB/s 01:03

aes256-ctr
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.1MB/s 01:14
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.2MB/s 01:06
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.7MB/s 01:03

arcfour128
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.3MB/s 01:12
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.2MB/s 01:13
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.3MB/s 01:12

arcfour256
ubuntu-10.04.1-server-i386.iso 100% 672MB 11.0MB/s 01:01
ubuntu-10.04.1-server-i386.iso 100% 672MB 11.2MB/s 01:00
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.9MB/s 01:02

arcfour
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.7MB/s 01:03
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.7MB/s 01:03
ubuntu-10.04.1-server-i386.iso 100% 672MB 10.2MB/s 01:06

blowfish-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.1MB/s 01:14
ubuntu-10.04.1-server-i386.iso 100% 672MB 9.2MB/s 01:13
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.9MB/s 01:16

cast128-cbc
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.3MB/s 01:21
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.4MB/s 01:20
ubuntu-10.04.1-server-i386.iso 100% 672MB 8.6MB/s 01:18


66% Differenz in der Zeit im Extremen ist ein guter Grund, sich darüber Gedanken zu machen. Bei Kopieraktionen über das Internet lohnt sich zusätzlich noch, die Kompression einzuschalten.

Wichtig: Das sagt nur etwas über Übertragungszeiten und nicht über die Qualität der Ciphers aus!

Anwendung ("-C" oder "Compression yes" nur bei langsamen Netzwerken):
scp -c aes192-ctr -C quelle host:/ziel
rsync -avze 'ssh -o "Ciphers aes192-ctr" -o "Compression yes"' quelle/ host:/ziel/

Oder gleich als Eintrag in die ~/.ssh/config:
Host *
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
Compression yes


Achtung: In der Config sollte man direkt mehrere Ciphers in Reihenfolge der eigenen Präferenzen eintragen, es kann sein, dass ein entferntes System eine bestimmte Cipher nicht beherrscht.

Trackbacks

Dirks Logbuch am : Cipher noch einmal ...

Vorschau anzeigen
Auf Nachfrage von Alex in den Kommentaren dieses Artikels, habe ich den Test auch noch mit Localhost gemacht. Mit diesem Skript: #!/bin/bashfor cipher in 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr arcfour128 arcfour256

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Venty am :

*Was je nach zu kopierenden Daten meist noch mehr ausmacht ist, wenn man mit -C die Kompression einschaltet.

Dirk Deimeke am :

*Zustimmung!

Kompression macht ins Internet und die Cipher im lokalen Netz am meisten Unterschied.

stfischr am :

*Man sollte noch bedenken, dass dieser Benchmark nur für dein System gültigkeit hat. Andere CPU und schon sieht das ergebnis anders aus. Auch das restliche System hat Einfluss auf das Ergebnis.

Dirk Deimeke am :

*Das gilt für jeden Benchmark. Aus diesem Grund gebe ich auch keine Empfehlung.

Gregor Fröhlich am :

*hi dirk. ich hab auch schon viele solche benchs gemacht und jetzt bin ich zum "ursprung" zurück gekommen, IPERF. ich gebe zu, dass ich das in der firma nur mit windoof mache, aber lnx versteht das auch. wir messen den eigentlichen durchsatz und geben dann Mbits/sec aus. hier mal 2 kleine bildchen dazu.

- speedtest
- resultat

gruss gregor

Dirk Deimeke am :

*Ja, solche Tests, wie auch bonnie oder bonnie++, eignen sich ganz hervorragend, um in einem genormten System Aussagen über Performance zu machen.

Bei Anwendungen bin ich der Meinung, dass man dann möglichst auch das Verhalten der Anwendung nachbauen sollte, weil sich das meist nicht mit einem genormten Test vergleichen lässt. Bei Webanwendungen leistet da jMeter sehr gute Dienste.

Alex am :

*Wenn du dazu noch folgenden Befehl als Vergleichsgröße stellen könntest wäre das schön:

dd if=/dev/zero bs=1MB count=1000 | ssh ::1 dd of=/dev/null bs=1MB

Dirk Deimeke am :

*Kann ich nicht, weil ich zum Einen kein IPv6 im lokalen Netz habe und weil lokal kein SSH-Server läuft. Der Vergleich wäre auch nicht hilfreich, weil Verschlüsselung und Entschlüsselung auf der gleichen Maschine passieren. Dazu kommt, dass das Lesen von /dev/zero - auch wenn es ein virtuelles Kernel-Device ist - noch in die Messung eingeht.

Alex am :

*1. hat dein Loopback Interface definitiv IPv6 (wenn das Kernelmodul geladen ist), sonst nutze 127.0.0.1
2. sollst du das natürlich auf dem SSH-Server ausführen
3. ist es Sinn und Zweck Ver- und Entschlüsselung auf der selben Maschine laufen zu lassen. Zusammen mit der Anzahl der Prozessoren kann man so den Einfluss der Verschlüsselung auf den Durchsatz einschätzen.
3. Das Lesen und Schreiben von virtuellen Devices sollte keinen nennenswerten Einfluss haben (ich kann von /dev/zero nach /dev/null mit >10GB/s kopieren)

Dirk Deimeke am :

*1. Ich sage ja, dass ich kein IPv6 habe.
2. Das verfälscht das Ergebnis, der Server ist eine Dualcore Maschine, der Client war ein Single Core Atom.
3. Siehe 2.
4. Also messen wir nur die Geschwindigkeit der Verschlüsselung.

Mache ich gerne, ich zweifele nur die Aussagekraft an.

Alex am :

*Ja es wird nur die Geschwindigkeit der Verschlüsselung gemessen. Hintergrund ist einfach, das ich mir nicht vorstellen kann (auch nicht bei einem Atom Prozessor), dass schon bei weniger als 10MB/s die Prozessoren schlapp machen. Zum Vergleich: Obiger Test ergibt bei mir ca. 80 MB/s (Ver- und Entschlüsselung zwar auf der selben Maschine aber unterschiedlichen Cores)

Dirk Deimeke am :

*So, ich habe den Test jetzt gemacht, der kommt in einen eigenen Blog-Artikel.

Wenig überraschend für mich ist, dass in einem Testlauf (ohne Messung), beide Cores zu 100% ausgelastet waren, auf einem lief der ssh-Daemon, auf dem anderen der SSH-Client.

Genau da spielt es dann schon eine Rolle, ob wie aufwendig ein Cipher ist, verlangt er mehr vom Server oder mehr vom Client. Ein Server mit 64bit kann pro Takt die doppelte Menge an Daten verarbeiten als ein 32bit-System.

Server ist mein Notebook mit Intel Core 2 Duo T8300, mit 2.4 GHz unter 64bit Ubuntu 10.04; Client war ein Netbook mit Intel Atom N280 mit 1.66 GHz unter 32bit Ubuntu 10.04.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen