Unverschlüsseltes SSH

rMarkus

rMarkus

Chuck The Plant
Hallo,

es gab mal die Möglichkeit bei SSH die Verschlüsselung abzuschalten:
Code: 
ssh -c none user@host

Da ich grosse Mengen durch ein lokales Subnetz mit SSH transportieren muss, würde ein Abschalten der Verschlüsselung mindestens den Faktor 4 an Geschwindigkeitsgewinn bringen. Die Daten werden hier durch ein Server-Subnetz in abgeschlossenen Räumen transportiert, so dass eine Datenverschlüsselung definitiv nicht notwendig ist.

Unverschlüsseltes SSH hätte den Vorteil, dass es quasi "at wirespeed" arbeitet, trotzdem eine sichere Authentifizierung macht, überall verfügbar ist und sauber funktioniert (im Gegensatz zu rsh).


Gibt es einen sauberen Weg eine unverschlüsselte SSH-Verbindung zu ermöglichen.


PS: blowfish als Verschlüsselung ist schneller als 3DES oder AES, aber "none" wäre ideal ;)
 
SSH hat folgende Vorteile:
- immer vorhanden
- kann durch NAT-Firewalls, FTP macht immre diesen 2. Port auf
- ftp kann keine Unterverzeichnisse transferieren (scp -rp ...)
- man kann viele Sachen wie tar, dump usw. durch ssh pipen:
Beispiel:
Code: 
cd quellverzeichnis; tar cvf - . | ssh user@host "cd /zielverzeichnis; tar xfp -"
 
netcat wäre eine weitere Möglichkeit, die ich in diesem Fall sogar ftp vorziehen würde (ftp muss idR ja konfiguriert werden, was bei netcat entfällt)
 
Nur so aus Neugier, wie kommst du auf den unglaublichen Performancegewinn von Faktor 4? Meinst du nicht eher 1.25?
 
Ich schaffe von FreeBSD 6.2(PentiumM 1.6) zu WinSCP(Athlon1666) ca 4MB/s, mit netcat oder FTP schaffe ich um die 11MB/s das sind ca. 4x.

Blowfish ist der cipher.


BTW: netcat is genauso einfach, man kann pipen, und wenn man ordner verschieben will nimmt man halt tar.
 
Das liegt nicht an SSH, sondern an WinSCP, das bekannterweise sehr langsam ist.

Gruß,

Ice
 
Das Problem ist, dass der Zielhost nur ein Pentium 3 mit 800 MHz ist und einige Terrabyte Daten dort hin und weg bewegt werden müssen.

Messungen mit netcat:
Code: 
[user@quellhost ~] time cat /dev/zero | nc -v -v zielhost 3000
 sent 376774656, rcvd 0
real    0m33.228s
user    0m0.133s
sys     0m1.747s


[user@quellhost ~] expr 376774656 / 1024 / 1024 / 33
# Ergbibt
10 MB/s

Zur Zeit ist die Zielmaschine nur mit 100 MBit angeschlossen. Die CPU war während des Tests zu ca. 25% ausgelastet, so dass noch Spielraum um Faktor 4 nach oben hin ist.

Messungen mit SSH (standard-Crypto, aes?)
Code: 
[user@quellhost ~] scp komprtestdatei.dat user@zielhost:/tmp
testdatei.test                                 70%  389MB   7.8MB/s   00:20 ETA

Messungen mit SSH (blowfish)
Code: 
[user@quellhost ~] scp komprtestdatei.dat user@zielhost:/tmp
testdatei.test                                 57%  318MB   9.6MB/s   00:23 ETA

Das Ergebnis erstaunt mich gerade etwas selber. Die CPU-Last war zwar 100%, aber die Werte scheinen mir etwas hoch.


PS: Zu WinSCP: WinSCP ist immer langsamer als die Unix-Varianten. Man kann die Geschwindigkeit aber auch dort steigern, wenn man auf "SCP" umschaltet und nicht den Default "SFTP" verwendet.
 
Zurück zum Thema:

Folgendes habe ich bisher in Erfahrung bringen können:

  1. In OpenSSH 1.x war es noch möglich mit "-c none" die Verschlüsselung zu deaktivieren
  2. Es gibt einen Patch für OpenSSH, mit dem man dies auch bei OpenSSH 2.x ermöglichen kann.

Der Patch ist mir aber etwas zu undurchsichtig dafür, dass ich sehr unternehmenskritische Daten damit kopiere. Hiermit meine ich die Zuverlässigkeit (exaktheit) der Daten und nicht deren Abhörbarkeit.
 
dann erzeuge md5 summen und vergleiche diese miteinander. damit sollte dann die unversehrtheit der daten gewährt sein.
 
md5 bei mehreren Terrabyte? Das ist dann auch nicht wirklich schnell, wenn er nach dem Transfer erstmal die Hashs vergleichen muss.
 
er muss es ja nicht direkt mit dem ganzen batzen machen... ein paar tests vorher, und im produktivbetrieb dann stichprobenartig, oder so
 
In meinem Fall lässt sich das nicht so einfach realisieren, denn es handelt sich um zig-tausende Dateien, bei denen auch alle die Berechtigungen stimmen müssen.
Es sind auch Links usw. dabei, die kann man quasi nicht testen.

Man könnte höchstens ein rekursives md5 über alles machen und dann den Unterschied betrachten.

Im Produktivbetrieb vergleichen ist auch nicht möglich, da sehr schnell alle Dateien angefasst werden. Die dicksten Brocken dabei sind Oracle-Tablespaces.
 
Ich habe mal die SCP Geschwindigkeit bei mir ausprobiert, die Übertragungsgeschwindigkeit hängt bei mir vom Empfängerrechner ab. Wenn der sonst nichts zu tun hat, komme ich über eine 100MBit Leitung auf 8MB/s. Allerdings ist die CPU auf dem Empfänger dann auch zu 100% ausgelastet (Pentium 4 - 1600).

Wenn du einen Multicore Empfänger hast würde es Sinn machen mehrere Übertragungen gleichzeitig zu starten um den Datendurchsatz zu erhöhen.
 
Dann ist mein Pentium 3 mit nur 800 MHz gar nicht mal so schlecht, denn der schafft 10,5 MB/s empfangend.
Sendend ist es noch mehr, da verschlüsseln weniger Resourcen als Entschlüsseln benötigt.

Mehrkern-CPUs bringen kaum Vorteile, da die wesentliche Arbeit (Krypto) nicht parallelisiert läuft. Eine zweite CPU könnte höchstens den TCP/IP-Overhead abnehmen, wobei man das auch anständige Netzwerkkarten schon machen.

Bei MehrCPU-Maschinen hänge ich in die Pipe noch zusätzlich auf jeder Seite ein gzip ein, welches den Stream vor dem Transport durch ssh komprimiert und nachher wieder dekomprimiert. Anders als die "-C"-Option von ssh läuft das dann nämlich parallelisiert. Leider ist der optimale Komprimierungsgrad für maximale Geschwindigkeit von der Datenart abhängig.

Code: 
# Beispiel:
cd /quellverzeichnis; tar cvf - . | gzip -2 | ssh -c blowfish user@zielhost "cd /zielverzeichnis; gzip -d | tar xfp -"

Für das Ausnutzen von mehr als zwei CPUs habe ich noch keine Idee.

Einen Geschwindigkeitseindruck bekommt man über den Speedtest von openssl.
Folgendes habe ich z.B. ermittelt für Blowfish
Code: 
Celeron D331 2666MHz 97189 kbyte/s
Xeon 2 MB  2800 MHz 102856 KByte/s
Pentium 3 800 MHz 28617 KByte/s
UltraSPARC IIIi 1600 MHz 68741 KByte/s
WRAP Geode 266 MHz 3504 KByte/s
Pentium 3 600 MHz 23064 KByte/s

Hier sieht man, dass die hochgelobte angebliche Integer-Performance der aktuellen(!) Sun nicht besonders vorhanden ist und den MHz-Nachteil in keiner Weise wegmacht.
Hier in KByte/s pro MHz
Code: 
CeleronD331: 36,45
Xeon 2MB: 36,73
P3-800: 35,77
UltraSPARC IIIi: 42,96
Geode: 13,17
P3-600: 38,44

Wenn man das in KByte/s pro EUR Kaufpreis angeben würde, würde niemand mehr eine Sun kaufen. ;)

Nach meinen Wissen nutzt SSH jedoch teilweise eigene Verschlüsselungsverfahren und nicht zwingend SSL. Daher sind die Werte nicht ganz vergleichbar und es werden wahrscheinlich dann auch keine Hardware-Crypto-Beschleuniger weiterhelfen.
 
nebenbei: weil du mit mehreren TB an Datenmenge arbeiten musst, würde ich an deiner Stelle wahrscheinlich mit einer netcat Pipe und star arbeiten. Das star anstelle von tar deswegen, weil du diverse Berechtigungen unbedingt erhalten musst. Die Prüfsummen der Dateien würde ich mit aide oder mtree speichern und nach dem Transfer autmatisiert abgleichen/diffen.
Selbstverständlich kannst du auch star über eine ssh Pipe verwenden - bei deinen n-TB an Daten mag es sein, dass du die Anzahl und Größe der star Archive auf ein maximales Maß beschränken möchtest. Nicht dass alle zig tausend Dateien in einem Archiv landen. Du entpackst gewiss on the fly wenn du die pipe zum Ziel Host legst.
 
Und was spricht nochmal dagegen es via netcat zu machen?

Oder noch besser ... warum nicht socat?
 
Zuletzt bearbeitet:
@Kamikaze:
ssh ist nach meiner Erfahrung nicht multithreaded, daher helfen mehrere CPUs nicht

@SierraX
Gegen Netcat spricht, dass die ständigen Portscans den netcat-listener aktiviert und beendet.
 
Bei mir öffnet der sshd ein Thread pro Verbindung. Parallele Verbindungen sind also eine Möglichkeit mehrere CPUs auszunutzen.
 
eigentlich forkt der sshd für jede Verbindung einen eigenen Prozess... Sollte also auf einem SMP system auch entsprechend gut funktionieren.

auf bald
oenone
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben