Dateien innerhalb einer Linuxumgebung übertragen

[Patsche]

Hi Leute,

ich suche gerade nach der schnellsten Methode Dateien über das private Netzwerk zu übertragen. Ich hatte das vor einiger Zeit mal mit Samba gemacht, wobei ich Samba ja nicht benötige, wenn nur Linuxgeräte verwendet werden. Nun verwende ich gerade ssh/sftp um Dateien zu übertragen, komme jedoch nur auf eine Übertragungsgeschwindigkeit von 1,3MB/s. So wird es mir von Thunar angezeigt. Hier läuft auf allen Geräten Jessie mit Xfce. Ich hatte auch von rcp gelesen bzw. von rsh-server und rsh-client. Damit soll ja ein unverschlüsselter Transfer möglich sein, aber da steige ic irgendwie nicht durch. Thunar kann jedenfalls nichts mit den unverschlüsselten Formaten anfangen, also: Terminal. Der Befehl soll laut dieser Quelle:
-> http://de.wikipedia.org/wiki/Cp_%28Unix%29#rcp.2C_ssh
so aussehen:

Code: Alles auswählen

rcp <Dateiname> <entfernter Benutzer@entfernter Rechner:/Verzeichnis/Dateiname>

Hat aber nicht geklappt. Nicht authorisiert. Habe aber nirgends finden können, wie ich mich vorher vom Client auf dem Server einloggen kann. Jedenfalls

Code: Alles auswählen

rsh <entfernter Benutzer@entfernter Rechner

hat nicht geklappt. Was nutzt ihr für eine solche Aufgabe?

[Saxman]

Ich nutze im Heimnetzwerk ebenfalls ssh bzw. sshfs. Wenn du das nur lokal benutzt, kannst du an der Protokollschraube drehen um mehr Durchsatz herauszuholen. Lokal ist die höchste Verschlüsselung bei der Übertragung ja nicht unbedingt notwendig. Eine Alternative unter Linux wäre ansonsten noch nfs. Das wäre wohl das Linux Pendant zu Samba.

[peschmae]

Ich benutze da auch immer ssh, einfach weils halt sehr praktisch ist; oft auch rsync-über-ssh weil man damit halt sehr gut unterbrechen/weiterfahren kann. Für mehr Tempo käme eventuell auch etwas udp-basiertes in Frage, z.B. uftp (gibts kein Debianpaket für). Habe ich aber selber für Lan-Anwendungen noch nie benutzt.

1.3 MB/s erscheint mir schon arg wenig - ist das ein WLan? Dann ist das eher noch normal. Oder ist das ein Kabel-Lan? Was ist am anderen Ende? Ich hatts auch schon mal dass so Transfers mit dem Kommandozeilen-scp (bzw. rsync -rsh=ssh) viel schneller liefen als per Gui-Dateimanager... (die genaue Ursache hab ich nie nachverfolgt, ich glaube die GUI hatte einfach Probleme mit so vielen Dateien...)

MfG Peschmä

[Patsche]

Ja das Netzwerk läuft über WLAN. Ich habe jetzt den Server mal testweise über die 1GBit LAN Verbindung an die Fritzbox (7330) angeschlossen und nochmal per GUI und CLI getestet. Also Client über WLAN und Server über LAN, aber das ergab auch keinen Geschwindigkeitszuwachs. Ich finde die Übertragungsgeschwindigkeit wirklich sehr langsam.

Wenn du das nur lokal benutzt, kannst du an der Protokollschraube drehen um mehr Durchsatz herauszuholen.

Wie geht das? Ich finde dazu leider auch nichts im Netz. Ich könnte noch nfs testen, aber das soll auch nicht viel schneller sein. Muss ich mir doch nen einfachen FTP-Server aufsetzen, oder wie sieht das aus?

[Saxman]

Wenn du das nur lokal benutzt, kannst du an der Protokollschraube drehen um mehr Durchsatz herauszuholen.

Wie geht das? Ich finde dazu leider auch nichts im Netz. Ich könnte noch nfs testen, aber das soll auch nicht viel schneller sein. Muss ich mir doch nen einfachen FTP-Server aufsetzen, oder wie sieht das aus?

Siehe z.B. hier. NFS ist im Übrigen normalerweise deutlich schneller als ssh.

[Patsche]

Ah okay. Ich hatte hier vorhin im Forum ein Thread gefunden, wo ein Benutzer alle Möglichen Szenarie ausprobiert hatte und da war nfs nicht wirklich schneller bei ihm. FTP hingegen schon. Ich bin jetzt noch einen Schritt weiter gegangen und habe die eine externe Festplatte direkt an die Fritzbox angeschlossen und eine Datei via Samba (smb) auf die Platte kopiert- Ergebnis: die Verbindung war sogar noch langsamer. Ich werde aber nfs auch nochmal selber testen. Vielen Dank schonmal an euch.

[Patsche]

So. Habe es jetzt mit nfs versucht. Habe die Freigabe mit den Optionen "rw" und "asynchron gemacht. Ergebnis: DEie Verbindung schwankt zwischen 500KB/s bis 2,5MB/s, also auch nicht wirklich eine Verbesserung. Ich werde mal weiter rumprobieren. Wenn ihr noch andere Tipps habt, dann her damit, denn so kann ich das nicht gebrauchen

Edit:
Die Verschlüsselung von ssh mit der Option "-c" mit arcfour und blowfish funktioniert hier nicht:

Code: Alles auswählen

ssh -c arcfour,blowfish-cbc sandra@192.168.178.30
no matching cipher found: client arcfour,blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

Es ist auch egal, ob ich es als Option übergebe, oder dauerhaft in die /etc/ssh/ssh_config eintrage.

[maledora4]

Code: Alles auswählen

...
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 17190442768, received 7798768 bytes, in 1574.2 seconds
Bytes per second: sent 10919856.0, received 4954.0
debug1: Exit status 0

1574.2 sec = 26:24 Min. für ~17GB

@peschmae hat oben schon das Kommandozeilentool scp erwähnt.
Ich stand mal vor dem Problem, eine DATEN-Partition von 17GB vorübergehend von einem Rechner auf einen Anderen zu übertragen. Der zweite Versuch sah so aus

Code: Alles auswählen

scp -r -p -v  /media/windows user@192.168.178.36:/media/DATEN

zurück ging es mit

Code: Alles auswählen

scp -r -p -v user@192.168.178.36:/media/DATEN/windows /media

und dauerte 25:79 Min.

Geholfen hatte mir man scp wodurch ich herausfand, dass mit dem Parameter -p der Zeitstempel erhalten bleibt.

[Patsche]

@peschmae hat oben schon das Kommandozeilentool scp erwähnt.

Hatte ich schon probiert. Ich zitiere mich mal selbst:

und nochmal per GUI und CLI getestet.

Habe es also mit scp probiert und komme nur auf 1,3MB/s. Ich weiß auch nicht, ob es vielleicht auch am Netzwerk liegt....
Der Router sollte jedenfalls mehr schaffen:
-> http://en.avm.de/products/fritzbox/fritzbox-7330/
Ich weiß nicht, welche Informationen ihr noch benötigt.

[DeletedUserReAsG]

Die Verschlüsselung von ssh mit der Option "-c" mit arcfour und blowfish funktioniert hier nicht:

Code: Alles auswählen

ssh -c arcfour,blowfish-cbc sandra@192.168.178.30
no matching cipher found: client arcfour,blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

Es ist auch egal, ob ich es als Option übergebe, oder dauerhaft in die /etc/ssh/ssh_config eintrage.

Du musst dich schon entscheiden – entweder arcfour oder blowfish. Beides auf einmal geht natürlich nicht.

[Patsche]

Du musst dich schon entscheiden – entweder arcfour oder blowfish. Beides auf einmal geht natürlich nicht.

Ah okay. Das geht aus der Anleitung nicht hervor.
->https://wiki.archlinux.de/title/SSH#Ges ... imierungen
Ich teste mal.

[DeletedUserReAsG]

Aufmerksames Lesen der Fehlermeldung hätte dich aber auch selbst drauf gebracht.

[Patsche]

Ich lese ja Aber es funktioniert trotzdem nicht.

Code: Alles auswählen

ssh -c arcfour sandra@192.168.178.30
no matching cipher found: client arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

Code: Alles auswählen

ssh -c blowfish-cbc sandra@192.168.178.30no matching cipher found: client blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

[DeletedUserReAsG]

Und wenn du sie nun nochmal liest, wirst du sehen, dass der Server keinen der beiden Cipher im Angebot hat. Warum auch immer das so ist – musst mal den Admin fragen.

Edit: muss mich korrigieren – die beiden Cipher sind offensichtlich exclusiv scp vorbehalten. ssh bringt bei mir die gleiche Liste, wie bei dir.

[Patsche]

Und wie bringe ich dem Server diese Verschlüsselungsart bei? Ich stehe gerade auf dem Schlauch. Danke für die Hilfe.

[DeletedUserReAsG]

Du könntest meinen Edit lesen: mit scp geht’s ziemlich sicher auch bei dir.

[Patsche]

Hab ich gemacht. Nur wie gebe ich jetzt scp die Verschlüsselungsart mit? Auch mit der Option "-c" oder muss ich die Option fest in die Konfiguration eingeben und scp übernimmt das dann automatisch?

[DeletedUserReAsG]

Code: Alles auswählen

       -c cipher
              Selects the cipher to use for encrypting the data transfer.  This option is directly passed to ssh(1).

[Patsche]

Ja hab ich auch gerade gelesen. Entschuldige. Bin nur ratlos. Also:

Code: Alles auswählen

scp -rpvc arcfour The\ Expendables\ Extended\ Edition/ marco@192.168.178.29:/home/marco
Executing: program /usr/bin/ssh host 192.168.178.29, user marco, command scp -v -r -p -t /home/marco
OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.178.29 [192.168.178.29] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sandra/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-3
debug1: match: OpenSSH_6.7p1 Debian-3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching cipher found: client arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
lost connection

[DeletedUserReAsG]

scp -c arcfour -r Quelle Ziel sollte den Job tun. Oder deine Config ist durch vorheriges Rumprobieren verschwurbelt.

[Patsche]

Leider nicht, das hatte ich auch schon probiert.

Code: Alles auswählen

scp -c arcfour -r The\ Expendables\ Extended\ Edition/ marco@192.168.178.29:/home/marco
no matching cipher found: client arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
lost connection

[dufty2]

Jungs, dat wird so nicht, denn

* sshd(8): The default set of ciphers and MACs has been altered to
remove unsafe algorithms. In particular, CBC ciphers and arcfour*
are disabled by default.

The full set of algorithms remains available if configured
explicitly via the Ciphers and MACs sshd_config options.

[Cae]

Euch ist schon klar, dass man gebrochene Ciphers und damit z.B. RC4 einfach nicht verwenden will? Auch wenn sie so schoen schnell sind? Wenn man eh kein Krypto haben will, kann man auch direkt rsync nehmen, mit echtem rsync-Daemon und nicht durch SSH getunnelt.

Gruss Cae

[Dimejo]

Hast Du schon mal die maximale Übertragungsgeschwindigkeit Deines Netzwerks (z.B. mit netcat) oder die maximale Leserate des Speichermediums (z.B. mit hdparm)getestet? Für mich liest sich das so als wäre hier nicht das Programm/Protokoll verantwortlich.

[DeletedUserReAsG]

Euch ist schon klar, dass man gebrochene Ciphers und damit z.B. RC4 einfach nicht verwenden will?

Dir ist schon klar, dass es hier um (W)LANs geht, und man da am liebsten die Verschlüsselung weglassen würde, wenn’s um z.B. was Pi-artiges an einem Ende geht?

Mich wundert gerade anhand dufty2s Quote nur die Tatsache, dass arcfour sehr wohl unter Archs 6.7p1 verfügbar ist – ich denke, sie pfuschen nicht an den Paketen rum?