Sichere Fernübertragung von Daten

[phlegmax]

Ich möchte gelegentlich einem entfernten Rechner größere Datenmengen (verschlüsselt) zukommen lassen und dafür aus Sicherheitsgründen keine Clouddienste oder ähnliches verwenden, bei denen die Daten auf fremden Servern liegen. Welche Möglichkeiten bietet da Debian? Eine möglichst einfache, aber sichere Lösung wäre mir lieb.

[wanne]

Ich würde sagen SSH ist und bleibt die einfachste Methode.

[uname]

Zu "rsync über ssh" bzw. sftp/scp sehe ich auch keine Alternativen. Aber natürlich könntest du die Daten auch packen, die Datei verschlüsseln und dann zu einem Cloud-Dienst hochladen. Beim Ziel wieder downloaden und entschlüsseln und entpacken. Das hat vor allem den Vorteil, dass auf keiner Seite ein Serverdienst laufen muss, der evtl. aufgrund von DSL-Routern schwer erreichbar wäre (Stichwort Port-Forwarding).

[phlegmax]

uname, könntest du deinen letzten punkt noch etwas ausführen? Es geht um zwei EInzelrechner, die ganz üblich über eine DSL-Verbindung im Internet hängen. Ist das dann mit ssh etc. instabil?

[schwedenmann]

Hallo

Es geht um zwei EInzelrechner, die ganz üblich über eine DSL-Verbindung im Internet hängen. Ist das dann mit ssh etc. instabil?

nein, außerdem bei Abbruch wird afaik da weitergemacht, wo die Verbindung unterbrochen wurde.

mfg
schwedenmann

[minimike]

Mit rsync kannst du Übertragungen nach Verbindungsabbruch wieder aufnehmen. Hast Du viele oder nur große Dateien splitte die besser als z.B. 7z Archiv in viele kleine. Angenommen du hast ein 1 GB Archiv in 1024 x 1 MB Dateien aufgeplittet. Bei Verbindungsabbruch geht eine Datei mit 1 MB kaputt. Was aber egal ist denn Du nimmst den Upload wieder auf bis alle Dateien da sind. Am Ziel brauchst Du nur das Archiv entpacken und kannst es dann Löschen um Platz zu Sparen. Die Methode war schon erfolgreich als es noch keine Cloud gab. Und ab und an komme ich immer noch nicht drum herum ohne es wieder zu Benutzen

[uname]

Wichtig ist dass das Ziel auch weltweit erreichbar ist. Wenn dem so ist geht es ganz leicht. Wichtig wäre nur noch, dass in
/etc/ssh/sshd_config

Code: Alles auswählen

Subsystem sftp /usr/lib/openssh/sftp-server

gesetzt ist und rsync auf beiden Systemen installiert ist.

Der Befehl auf dem Client wäre dann:

Code: Alles auswählen

rsync -av /pfad/von/quelle/ user@weltweite-ip-oder-name:/pfad/zum/ziel/

Mit dem Slashes am Ende von quelle und ziel musst du aufpassen. Lese das Manual. Sonst kannst du wohl mal deine Verzeichnisse zerlegen.

Wenn du nun den Public-SSH-Key von der Quelle dem Ziel bekannt machst braucht du kein Passwort und es ist noch sicherer. Auch kannst du den Befehl immer wiederholen. Es werden dann die Änderunen neu kopiert. Willst du Dateien der Quelle auch am Ziel löschen kannst du noch "--delete" nutzen. Hiermit solltest du aufpassen, da falsche Pfade zu Datenverlust beim Ziel führen können.

[catdog2]

Mit rsync kannst du Übertragungen nach Verbindungsabbruch wieder aufnehmen. Hast Du viele oder nur große Dateien splitte die besser als z.B. 7z Archiv in viele kleine. Angenommen du hast ein 1 GB Archiv in 1024 x 1 MB Dateien aufgeplittet.

Mit rsync muss man das ja gerade nicht.

Wenn dem so ist geht es ganz leicht. Wichtig wäre nur noch, dass in
/etc/ssh/sshd_config

Code: Alles auswählen
Subsystem sftp /usr/lib/openssh/sftp-server


gesetzt ist und Debianrsync auf beiden Systemen installiert ist.

SFTP sollte Standarmäßig eh aktiv sein und rsync ist SFTP ziemlich egal, das pipet sein Zeug nur durch SSH.

[uname]

SFTP sollte Standarmäßig eh aktiv sein und rsync ist SFTP ziemlich egal, das pipet sein Zeug nur durch SSH.

Also für meinen Befehl muss es mindestens auf dem Client vorhanden sein. Wie das mit dem Server ist weiß ich nicht. Aber natürlich kann man die Daten auch ohne rsync direkt mit scp bzw. sftp kopieren.

[catdog2]

rsync muss natürlich auf beiden Seiten vorhanden sein wenn man es nutzen will. Nur hat rsync nichts mit SFTP am Hut.

[Dogge]

Mit dem Slashes am Ende von quelle und ziel musst du aufpassen. Lese das Manual. Sonst kannst du wohl mal deine Verzeichnisse zerlegen.

Ich zitiere mich mal selbst:

Bei der Angabe der Quelle ist es wichtig darauf zu achten, dass zwischen "Quelle" und "Quelle/" un­ter­schie­den wird.

Code: Alles auswählen

rsync -a /home/martin/ /media/martin/USB-Festplatten-UUID/Backup

würde nur die Dateien im Ordner martin zum Ziel übertragen, nicht den Ordner martin selbst. Um den gesamten Ordner zu sichern muss man

Code: Alles auswählen

rsync -a /home/martin /media/martin/USB-Festplatten-UUID/Backup

ausführen.

Um nach Verbindungsabbruch unvollständige Übertragungen fortsetzen zu können benötigt man afair noch die Option -P.

[Cae]

Ich wuerde Krypto (GPG, aespipe, etc.) draufwerfen und das Produkt per Torrent durch die Gegend schieben. Das Torrent-Protokoll ist genau dafuer gedacht, grosse Datensaetze fehlertolerant in die Welt zu schiessen. Ausserdem kannst du sehr simpel einen weiteren Uplink einbinden, z.B. bei einem Nachbarn oder Bekannten: Du kopierst deine Torrent-Quelldateien auf eine Festplatte, traegst sie zum zweiten Uplink und laesst sie von dort aus seeden.

Uebrigens kann man mit Krypto auch verhindern, dass Anbieter des Cloudspeichers und zufaellige Mithoerer Rueckschluesse ueber die uebertragenen Daten ziehen koennen. Allerdings gibt man damit dem Cloudanbieter einen Existenzgrund, was vielleicht keine so gute Idee ist. Zu beachten ist jeweils, dass auch tatsaechlich starke Schluessel verwendet werden, also nicht Passworte a la "asdf123456", sondern eher 256 Bit aus /dev/random. Die Schluesseluebertragung sollte idealerweise mit asymmetrischer Krypto erfolgen, z.B. GPG. Uebrigens macht GPG das auch direkt intern, wenn man ihm 20GB Daten zum Verschluesseln vorwirft.

Ein Nachteil bei der oben beschriebenen Ende-zu-Ende-Verschluesselung (im Gegensatz zur Transportverschluesselung wie per SSH) liegt darin, dass man beim Ver- und Entschluesseln kurzfristig doppelt soviel Platz braucht, wie man Nutzdaten hat. Durch Aufteilen in z.B. 100MB-Pakete laesst sich dieses Problem allerdings elegant umgehen.

Gruss Cae

[minimike]

Noch mal Klugscheiss Ich meine damit natürlich Rsync via SSH

rsync -ayvze ssh /path/to/directory root@target:/path/to/directory

[wanne]

uname, könntest du deinen letzten punkt noch etwas ausführen? Es geht um zwei EInzelrechner, die ganz üblich über eine DSL-Verbindung im Internet hängen. Ist das dann mit ssh etc. instabil?

instabile nicht. Aber es gibt beim Einrichten erstmal 2 Probleme:

1. Deutsche Anbieter wechseln typischerweise die IPs alle 24h. Wenn du den Rechner an den du übertragen willst also auch nach tagen wieder finden willst, musst du die IP irgend wo hinterlegen. DynDNS macht das. Du holst dir bei irgend einem DynDNS Anbieter einen Menschenlesbaren (z.B. phlegmax.nsupdate.info) Namen und ddclient oder dein Heimrouter meldet dann deine IP wenn sie sich änder an einen Server.
   Dann kannst du einfach scp [src] phlegmax.nsupdate.info:[dest] oder rsync phlegmax.nsupdate.info machen.
2. Die meisten Heimrouter finden direkte Übertragungen ohne Clouddienst in der Mitte extrem gefährlich und blockieren das. Wenn du also übertragen willst musst du da den Port für SSH (per default 22) freischalten. Das stichwort dazu heißt meistens portforwarding.

[uname]

Die meisten Heimrouter finden direkte Übertragungen ohne Clouddienst in der Mitte extrem gefährlich und blockieren das. Wenn du also übertragen willst musst du da den Port für SSH (per default 22) freischalten. Das stichwort dazu heißt meistens portforwarding.

Naja. Das Problem ist eigentlich eher, dass wenn man einen Heimrouter hat, dass im Heim geroutet wird. Da man jedoch vom Provider nur eine IP bekommt hat man dann im internen Netz interne IP-Adressen. Und interne IP-Adressen werden im Internet nicht geroutet, da diese ja millionenfach existieren und woher soll das schlaue Internet wissen wohin die Pakete dann sollen. Mit blockieren hat das weniger zu tun. Selbst vollkommen ohne Firewall, Portsperren oder mit Routing-Regeln von außen nach innen wird rein gar nichts passieren, da Zielpakete aus internen Netzwerken (z.B. 192.168.1.0/24) das äußere Heimrouter-Netzwerk-Interface nie erreichen werden.

[phlegmax]

Exzellent, vielen Dank für eure zahlreichen Antworten!!

[spiralnebelverdreher]

Die meisten Heimrouter finden direkte Übertragungen ohne Clouddienst in der Mitte extrem gefährlich und blockieren das. Wenn du also übertragen willst musst du da den Port für SSH (per default 22) freischalten. Das stichwort dazu heißt meistens portforwarding.

Naja. Das Problem ist eigentlich eher, dass wenn man einen Heimrouter hat, dass im Heim geroutet wird. Da man jedoch vom Provider nur eine IP bekommt hat man dann im internen Netz interne IP-Adressen. Und interne IP-Adressen werden im Internet nicht geroutet, da diese ja millionenfach existieren und woher soll das schlaue Internet wissen wohin die Pakete dann sollen. Mit blockieren hat das weniger zu tun. Selbst vollkommen ohne Firewall, Portsperren oder mit Routing-Regeln von außen nach innen wird rein gar nichts passieren, da Zielpakete aus internen Netzwerken (z.B. 192.168.1.0/24) das äußere Heimrouter-Netzwerk-Interface nie erreichen werden.

Verstehe deinen Einwand nicht ganz, uname. Genau diesen Punkt, wie man einen typischen Heimrouter mit seinen wechselnden IP-Adressen umgeht, hat wanne in seinem Beitrag doch unter Punkt 1 erläutert.

[uname]

Das stimmt alles. Ich wollte auch nur darauf eingehen, dass "die meisten Heimrouter ... und blockieren das". Es wird nichts blockiert. TCP/IP sieht einfach das Routing von internen IP-Adressen im Internet nicht vor. Um doch einen internen Dienst zu erreichen muss man dann dem Router gezielt sagen, dass per TCP-Forwarding am äußeren Interface ein Port lauscht, der dann nach innen weitergeleitet wird.

[Dogge]

Ist ja irgendwie auch logisch. Angenommen ich habe im lokalen Netz drei Rechner mit SSH-Server auf Port 22. Woher soll der Router wissen, welchen man erreichen möchte? Außerdem ist es ja häufig auch praktisch, dass man im lokalen Netz Serverdienste installieren kann ohne sich Sorgen machen zu müssen. Dieses "Opt-In" per Portforwarding im Router, falls man etwas von außen erreichen möchte, finde ich recht sinnvoll auch wenn es so nicht gedacht war, sondern das nur ein Nebeneffekt ist.

[minimike]

Man kann ja SSH und HTTPS hinter einem SSL Multiplexer hängen. Nachteil teuer weil relativ hohe CPU Last beim Aufruf von HTTPS Seiten. Bei wenig Aufrufen aber nicht so wichig. Vorteil SSH und HTTPS sind extern via Port 443 aufrufbar.sslh kann das. Somit versteckt man SSH hinter einer HTTPS Seite.

[wanne]

Das stimmt alles. Ich wollte auch nur darauf eingehen, dass "die meisten Heimrouter ... und blockieren das". Es wird nichts blockiert. TCP/IP sieht einfach das Routing von internen IP-Adressen im Internet nicht vor.

Interne Adressen gibt es in TCP/IP gar nicht.

Angenommen ich habe im lokalen Netz drei Rechner mit SSH-Server auf Port 22. Woher soll der Router wissen, welchen man erreichen möchte?

Anhand der IP? Das ist eigentlich mal deren Sinn gewesen, bevor man dazu Ports genommen hat und die IPs nur noch für tracking Zwecke verwendet...

Außerdem ist es ja häufig auch praktisch, dass man im lokalen Netz Serverdienste installieren kann ohne sich Sorgen machen zu müssen. Dieses "Opt-In" per Portforwarding im Router, falls man etwas von außen erreichen möchte, finde ich recht sinnvoll auch wenn es so nicht gedacht war, sondern das nur ein Nebeneffekt ist.

Für alle die das so haben wollen gibt es eigentlich unter jedem Betriebssystem eine entsprechende Regel.
Unter Windows "Eingehende Verbindungen aus dem Internet verbieten" (ist sogar default) und unter Linux ist das dann

Code: Alles auswählen

iptables -A INPUT -p tcp -s 192.168/16 -j ACCEPT
ip(6)tables -A INPUT -p tcp --syn -j REJECT

Und ist bei den meisten typischen Desktop Distros auch default. (Fedora, Mandriva, Mageia)
Und nur weil ein paar Betriebssysteme (Windows XP, Debian, besonders idiotische Drucker) das anders machen (und ein Nutzer darüber noch überrascht sind) allen massenhaft steine in den Weg zu legen ist IMHO absolut doof. Ich meine jeder vernünftige dienst hört sowieso nur auf's lokale Netz , wenn man ihm das nicht ausdrücklich anders sagt. Das ist jetzt kein Hexenwerk. Windows Freigaben schaffen das. Praktisch alle Streaming Server, die ganzen Proxys und viele Drucker bekommen das auf die Reihe.
Sehe das absolut nicht ein wieso meine Fritzbox mir meinen SSH blockiert (und die ist auch noch so kaputt, dass man das nicht abschalten kann und der Provider verbietet mir die auszutauschen). Nur weil HP es nicht auf die Rehe bekommt, dass seine Drucker per default nicht aus dem Internet erreichbar sind.
Aber können wir das in einen anderen Thread verschieben? Hat absolut nichts mehr mit der Ursprünglichen Diskussion zu tun.

[BerndHohmann]

Ich hab das gleiche Problem damals so gelöst, dass ich eine nutzlose ipv4 VM bei 1&1 als OpenVPN-Server aufgesetzt habe. Mittlerweile läuft darüber so eine Art "Europaweites RAID-5" für meine Daten, Endpunkte sind Freunde in den jeweiligen Ländern.

Bernd

[uname]

Interne Adressen gibt es in TCP/IP gar nicht.

Dann meine ich eben http://de.wikipedia.org/wiki/Private_IP-Adresse
Die werden im Internet nicht geroutet

Code: Alles auswählen

iptables -A INPUT -p tcp -s 192.168/16 -j ACCEPT

Erscheint mir sinnfrei. Aus dem Adressbereich wird man nie eine Kommunikation erhalten. Aber auch als Ziel unerreichbar. Maximal sinnvoll bei einem VPN.

http://www.dnstools.ch/visual-traceroute.html

Code: Alles auswählen

guest@dnstools.ch:~> traceroute 192.168.42.42 
1 gw.f.netclusive.de (89.110.131.1) 1.526 ms 
2 89.202.113.81 (89.202.113.81) 2.361 ms !N 

Wie man sieht weiß der Router des Netzwerks nicht wo im Internet er 192.168/16 erreichen soll und verwirft somit eigenständig die Zielpakete.