Happy Penguin schrieb:

Was wäre mit folgender Alternative:

• sudo mount.davfs -o gid=cdrewing,uid=cdrewing https://dav.trendmicro.safesync.com /media/Safesync

• encfs /media/Safesync/EncFS /media/Safesync/EncFS_open

Hmm, habe ich noch nie ausprobiert, denn Du mountest so ja eine Resource in eine Resource.

Dann hätte man im remote-Verzeichnis sowohl die verschlüsselten als auch die sichtbaren Daten, bis man sie wieder aushängt und keine "leeren" Verzeichnisse in /media (außer Safesync), wenn man offline ist. (Zugegeben ein minimaler Unterschied, aber ist auch eine eher prinzipielle Frage. Und vielleicht gibt es ja weitere Vor- und Nachteile ?)

Im Zweifelsfall, wenn das doch gehen sollte, dann hast Du *remote* nicht nur die verschlüsselten Daten (was ja ok ist), sondern auch die entschlüsselten. Die Frage, die sich mir dann stellt, ist, warum überhaupt verschlüsseln, wenn sie soundso entschlüsselt remote vorliegen werden? Zweite (praktisch orientierte) Frage: hast Du so viel Bandbreite? Ich würde nicht ausschließen, dass EncFS/WebDAV die jeweiligen Daten erst verschlüsselt downloadet, um sie dann lokal zu entschlüsseln und dann wieder entschlüsselt hochzuladen (und dann darfst Du entschlüsselt auf sie zugreifen). Also zweimal den Flaschenhals Deiner Bandbreite überqueren, so masochistisch bin selbst ich nicht

Gibt es in dem Pfad noch kein EncFS, dann erkennt das System das und startet den Einrichtungsassistenten.

*hmm* Das muß ich mir dann nochmal genauer anschauen. Was macht denn der Einrichtungsassistent, wenn im verschlüsselten Verzeichnis bereits Dateien liegen, ich die aber jetzt unbedingt in einem anderen Verzeichnis als dem originalen angezeigt bekommen möchte ?

Wenn EncFS ein bereits vorhandenes verschlüsseltes Dateisystem findet, dann versucht es, dieses zu mounten. Anderenfalls verfällt es automatisch in den Einrichtungsmodus. Keine Panik!

Innerhalb dessen kannst Du das auch angeben, ob der Pfad Bestandteil der verschlüsselten Daten sein soll.

Na, dann auf keinen Fall - könnte ja auch sein, daß ich mal von einem anderen Rechner auf die verschlüsselten remote-Daten zugreifen möchte und der mountpoint aus irgendeinem Grund anders heißt.

Ich habe das wie gesagt deaktiviert

Ich wüsste auch nicht, warum man den Pfad mitverschlüsseln müsste ... ?

Der Pfad an sich wird immer mit verschlüsselt, da steht dann also nicht /pfad/zur/date/datei.txt sondern /qeofgqoefg/kqedfgqefg/effg612wfog/lwfg7387. Nur stelle ich es so ein, dass Du lwfg7387 zum Beispiel von /qeofgqoefg/kqedfgqefg/effg612wfog/ nach /qeofgqoefg/38gfkgewfg/lgdf38 verschieben kannst, und die Datei wird deswegen nicht unbrauchbar. Der voranstehende Pfad gehört in meinem Fall also nicht zum Chiffrierschlüssel.

CDrewing schrieb:

Was wäre mit folgender Alternative:...

Hmm, habe ich noch nie ausprobiert, denn Du mountest so ja eine Resource in eine Resource.

Das war die Idee. Wenn die Resource wie ein normales / lokales Filesystem verwendet werden kann, müsste das ja grundsätzlich auch gehen.

Die Frage, die sich mir dann stellt, ist, warum überhaupt verschlüsseln, wenn sie soundso entschlüsselt remote vorliegen werden?

Das wäre der erste Nachteil, wenn es so abläuft, daß die entschlüsselte(n) Datei(en) dann zeitweise auf der remote-Platte liegen (und nicht "on the fly" entschlüsselt und nur dargestellt werden)...

Zweite (praktisch orientierte) Frage: hast Du so viel Bandbreite?

Davon träume ich höchstens ab und zu mal.

Ich würde nicht ausschließen, dass EncFS/WebDAV die jeweiligen Daten erst verschlüsselt downloadet, um sie dann lokal zu entschlüsseln und dann wieder entschlüsselt hochzuladen (und dann darfst Du entschlüsselt auf sie zugreifen). Also zweimal den Flaschenhals Deiner Bandbreite überqueren, so masochistisch bin selbst ich nicht

... und das wäre der zweite Nachteil.
(Ich teile Deine Befürchtung - und auch Deine Begrenzung bzgl. Selbstgeißelung. )

Wenn EncFS ein bereits vorhandenes verschlüsseltes Dateisystem findet, dann versucht es, dieses zu mounten. Anderenfalls verfällt es automatisch in den Einrichtungsmodus. Keine Panik!

OK, ich bin beruhigt.

Der Pfad an sich wird immer mit verschlüsselt, da steht dann also nicht /pfad/zur/date/datei.txt sondern /qeofgqoefg/kqedfgqefg/effg612wfog/lwfg7387. Nur stelle ich es so ein, dass Du lwfg7387 zum Beispiel von /qeofgqoefg/kqedfgqefg/effg612wfog/ nach /qeofgqoefg/38gfkgewfg/lgdf38 verschieben kannst, und die Datei wird deswegen nicht unbrauchbar. Der voranstehende Pfad gehört in meinem Fall also nicht zum Chiffrierschlüssel.

OK, verstanden.

Aufgrund der beiden (vermuteten) Nachteile wird es somit wohl auf "remote verschlüsselt, lokal entschlüsselt" hinauslaufen. (Anders wäre es wohl nur dann sinnvoll, wenn man mit einem schwachen client zugreift und die Entschlüsselung direkt auf dem server laufen lassen könnte - aber das ist dann ein anderes Anwendungsszenario.)

Nochmal vielen Dank für Deine Hilfe.

Gerne. Ich selbst werde - sobald ich hier mal etwas aufgeräumt habe -von Truecrypt auf EncFS umstellen. Das ist einfach flexibler. Und das macht ja nichts, dass Du für die Phase des gemountet sein entschlüsselte Daten auf Deinem Rechner haben wirst, die werden ja, sobald der Unmount Prozeß abgeschlossen ist, wieder gelöscht.

P.S.: So, jetzt suche ich noch einen unter Linux brauchbaren unlimitierten Backupservice. Crashplan war die ersten zwei Wochen genial (volle Bandbreite bei VDSL50), seit einer Woche kriecht es mit 400-1000 kBit.

CDrewing schrieb:

Gerne.

Ich selbst werde - sobald ich hier mal etwas aufgeräumt habe -von Truecrypt auf EncFS umstellen. Das ist einfach flexibler.

Momentan habe ich auch noch zwei Truecrypt-Container im lokalen Einsatz. Von denen trenne ich mich, wenn ich mein System irgendwann komplettverschlüsselt habe.

Und das macht ja nichts, dass Du für die Phase des gemountet sein entschlüsselte Daten auf Deinem Rechner haben wirst, die werden ja, sobald der Unmount Prozeß abgeschlossen ist, wieder gelöscht.

Auf meinem eigenen Rechner habe ich damit kein Problem - meine Aussage war auf die Entschlüsselung auf dem server (in Variante 2) bezogen. Da will ich ja gerade keine entschlüsselten Dateien rumliegen haben. Nichtmal zeitweise, denn wer weiß, wer dann gerade dort vorbeischaut.

P.S.: So, jetzt suche ich noch einen unter Linux brauchbaren unlimitierten Backupservice.

Toitoitoi !

Crashplan war die ersten zwei Wochen genial (volle Bandbreite bei VDSL50), seit einer Woche kriecht es mit 400-1000 kBit.

Woran liegt's ?
Und falls Du was Brauchbares findest: Laß es uns wissen.

CDrewing schrieb:

Gerne. Ich selbst werde - sobald ich hier mal etwas aufgeräumt habe -von Truecrypt auf EncFS umstellen. Das ist einfach flexibler. Und das macht ja nichts, dass Du für die Phase des gemountet sein entschlüsselte Daten auf Deinem Rechner haben wirst, die werden ja, sobald der Unmount Prozeß abgeschlossen ist, wieder gelöscht.

P.S.: So, jetzt suche ich noch einen unter Linux brauchbaren unlimitierten Backupservice. Crashplan war die ersten zwei Wochen genial (volle Bandbreite bei VDSL50), seit einer Woche kriecht es mit 400-1000 kBit.

Wenn es "nur" darum geht den Onlinespeicher als Backup-Ziel zu verwenden, dann könnt ihr das alles einfacher haben. Schaut euch mal Duplicati an. Duplicati macht verschlüsselte, inkrementelle, komprimierte Backups und speichert diese auf verschiedenen Online-Speichern wie Amazon S3, Windows Live SkyDrive und "normalen" Servern, die WebDAV, SSH, FTP sprechen. Seit der letzten Beta gibt es auch Installationspakete für Ubuntu und andere Distributionen.

Trev

@Trevor:

Liest sich gut, jetzt brauche ich nur bezahlbare 750 GB Speicher. $0.15/GB ist in der Summe ein bisschen zu viel.

CDrewing schrieb

P.S.: So, jetzt suche ich noch einen unter Linux brauchbaren unlimitierten Backupservice. Crashplan war die ersten zwei Wochen genial (volle Bandbreite bei VDSL50), seit einer Woche kriecht es mit 400-1000 kBit.

Ich habe mich halb tot gesucht im Netz. Und keine brauchbare Alternative gefunden, die für große Datenmengen geeignet ist. Andere Dienste haben immer Fallstricke (Maximale Dateigrößen, nur bestimmte Dateiformate, Drosselung ab bestimmten Datenmengen, nicht lauffähig unter Linux, ...) Daher bin ich auch trotz des Absinkens (übrigens zu ungefähr dem gleichen Zeitpunkt, von dem du auch berichtest) meiner Datenrate auf tlw. unter 1Mbit/s bei Crashplan geblieben. Die Software ist einfach schon zu genial ^^

Dann habe ich mehrfach Kontakt mit Crashplan aufgenommen, die die Schuld auf meinen ISP schoben. Mit dem hab ich auch mehrfach Kontakt aufgenommen und mich Alternativ auch mal ins XWin eingeklemmt, bei dem ich Geschwindigkeiten von gemessenen 18 Gbit/s in die USA erreichen könnte (na gut, mehr als 1Gbit/s war in Ermangelung eines schnelleren Ports an meinem Laptop nicht drin ) aber auch dort kam ich nur auf die gleichen niedrigen Datenraten. Ein paar weitere Mails zum Crashplan-Support und dann gestand man mir, dass das Problem doch bei denen liegen würde. Sie hätten derzeit Probleme mit einer schneller wachsenden Userzahl als die Serverfarmen wachsen. Das würde derzeit in einigen Serverclustern zu einer zu hohen Auslastung führen. Sie versprachen mir auch, dass sie daran schon arbeiten würden, es aber noch ein bisschen dauern könne. Das ist nun wieder ein paar Wochen her. Seitdem gab es immer mal wieder einen sprungartigen Anstieg. Inzwischen kann ich wieder zwischen 6 und 10 Mbit/s im Upload erreichen über mein VDSL50. Über xwin hab ichs noch nicht wieder ausprobiert. Allerdings sollte man bei großen Backups und großen Dateien in Kombination mit einer schnellen Internetleitung (>2Mbit/s Upstream) in den Einstellungen unbedingt die Komprimierung ausschalten und die Datendeduplizierung auf Minimum stellen. Zumindestens bis zum Abschluss des ersten Vollbackups. Ansonsten ist die CPU der limitierende Faktor - mein Core i7-2600 schafft mit Komprimierung Ein und Deduplizierung auf Maximum nur 4-5 Mbit/s, dann hängt die CPU mit maximalem Turbo-Boost und 100% Auslastung auf einem Kern am Maximum und die Internetleitung ist dann nicht mehr der limitierende Faktor ^^

So hab ich in den letzten zwei Monaten ca. 3TB bei Crashplan untergebracht, Tendenz steigend