Sicherer Dateiaustausch mit Windows

h^2

h^2

hat ne Keule +1
Hallo Leute,

also ich muss da ein riesiges Datenpaket ohne Internet übertragen, Quelle FreeBSD, Ziel Windows. Soll durch eine verschlüsselte Festplatte gehen, hier nun die Frage (weil ich sowas sonst nie brauche):
* Geht inzwischen Truecrypt mit FreeBSD?
* Und NTFS auf FreeBSD?
* Und NTFS auf Truecrypt auf FreeBSD?
(FAT32 geht nicht, wegen Dateigrößen)

Danke!
 
Also Truecrypt weiß ich nicht, aber es gibt da einen Port. NTFS läuft mit ntfs-3g einwandfrei, allerdings sollte man dafür das fuse.ko aus 10-CURRENT nutzen. Es sei den man steht auf Panics am Morgen. :) Das Modul gibt es als Port: http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 Den vorhandenen fusefs-kmod Port damit ersetzen, einmal "make makesum" ausführen und anschließend den Port, fusefs-libs und alle Fuse-Module neubauen.
 
Ich hatte Truecrypt vor einiger Zeit unter PC-BSD laufen, dort gibt es ein PBI, also sollte es grundsätzlich laufen. Eine Alternative wäre noch EncFS das befindet sich auch in den Ports und läuft ganz gut. Im Notfall sollte ein geschütztes Archiv auch gehen.

Grüße
 
Ich würde nur 7-Zip nehmen da ist doch eine anständige Verschlüsslung dabei. Alle Daten in ein Archiv gepackt und gut ist es. Das bekommt man dann auf jedem System wieder entpackt.

Grüße
 
Obwohl es von Truecrypt ein PBI gibt, habe ich damit unter FreeBSD bisher noch keinen Erfolg gehabt.

Ich würd moment auch 7zip mit Verschlüsselung vorschlagen, wenn es von der Sicherheit her akzeptabel ist.
 
So gut bsdtar ansonsten auch funktioniert hier würde ich vorsichtig sein, wenn du mehr als nur Namen und Inhalt der Dateien erhalten willst.
 
Jo ich würde den Quatsch auch zusammen zippen und dann mit Openssl die Datei verschlüsseln (z.B symmetrisch, AES sollte hier erste Wahl sein).

Oder brauchst du noch die Dateirechte/etc.?
 
Was nutzt den 7zip für eine Verschlüsselung? Gibt's das für BSD?

ich würds auch zusammenpacken (tar, zip, you name it) und anschließend mit openssl oder gnupg verschlüsseln. Ich würd allerdings eher auf Laptop und Netzwerk setzen ;)
 
Fuse unter FreeBSD-9 ist inzwischen eine ganz schlechte Idee. Seit den NTFS-Verbesserungen funktionieren auch alle anderen fuse-Dateisysteme (sshfs, wdfs, smbnetfs etc.) nicht mehr.
 
Nun, ich habe keine gute Meinung von der Userland Dateisystem Idee. Im verlauf des 8er Zweig hat das alles mal ziemlich gut funktioniert. Mit 9 kamen Probleme dazu, die wohl in 10 gefixt sind was aber zu noch mehr Problemen mit 9 geführt hat.

Kurz gesagt, selbst wenn es läuft, gibt es keinen Verlass, dass das so bleibt.
 
Du kannst 7-zip nehmen, das nutzt soweit ich mich erinnere AES. Das wäre dann nur ein involviertes Programm. Und 7-zip funktioniert auch unter Windows. EDIT: Unter Unix heißt das p7zip.

Alternativ kanst du auch eine ext2 - Partition nutzen, aber beim Erstellen aufpassen, ein Linux-Default-Wert sorgt dafür, dass FreeBSD das nicht lesen kann. Ich erinner mich gerade nicht welcher das war, also besser unter FreeBSD erstellen, dann gehts.
Krypto wäre dann aber noch nachzurüsten.
 
@Kamikaze: Hast du mal das neue FUSE-Modul probiert, was ich oben verklingt habe? Ich hatte damit bisher keine Probleme, aber nutze auch fast nur NTFS.
 
Hm, also das Szenerio ist so, dass an Empfängerseite, die Platte mit den Daten möglichst in der Form auch einfach genutzt werden können sollte. Die ganzen Daten einmal zu entschlüsseln und dann noch zu entpacken ist keine praktikable Lösung.
Die Hauptfrage ist ob ich einmal an einem Windows eine verschlüsselte Truecrypt Partition anlegen kann und dann von FreeBSD halt die Daten drauf. Das muss nicht dauerhauft und regelmäßig klappen, sondernnur einmal 1TB drauf und gut ist. Ich habe hier sozusagen ein Riesenbackup eines Windows-Users was mittels ein neuen Festplatte per Post den Weg zu der Person zurück finden soll.

edit: Das FreeBSD was die Daten bereit hält ist noch ein 8.3. Das koennte aktualisiert werden auf ein 9.1, aber vielleicht wäre 8 ja noch ein Vorteil, laut der hier geäußerten Kommentare?
 
h^2 schrieb:
Hm, also das Szenerio ist so, dass an Empfängerseite, die Platte mit den Daten möglichst in der Form auch einfach genutzt werden können sollte. Die ganzen Daten einmal zu entschlüsseln und dann noch zu entpacken ist keine praktikable Lösung.
Zum Vergrößern anklicken....

:eek: kann der Windows user nicht doppel Klicken und auf der Tastatur rum Klimpern oder soll die Lösung dauerhaft in dem Windows gerät laufen? Ich glaube du solltest mehr Details erzählen.
 
Ich glaube h2 will das einfach wie TrueCrypt haben. Paswort eingeben und der verschlüsselte Container wird eingehängt. So wie er es beschrieben hat hört es sich nach einer einmal Aktion an. Daten verschlüsseln, in anderes Büro/Bundesstaat/über die Grenze/auf den Mond bringen und dort wieder entschlüsseln, fertig.
 
carbuncle schrieb:
Ich glaube h2 will das einfach wie TrueCrypt haben. Paswort eingeben und der verschlüsselte Container wird eingehängt. So wie er es beschrieben hat hört es sich nach einer einmal Aktion an. Daten verschlüsseln, in anderes Büro/Bundesstaat/über die Grenze/auf den Mond bringen und dort wieder entschlüsseln, fertig.
Zum Vergrößern anklicken....

Dann wäre entpacken aber gleichwertig. Nur wenn die Daten dauerhaft auf der Platte bleiben müssen, weil kein Platz oder was auch immer, wäre entpacken nicht wirklich hübsch.
 
ähnliche Probleme habe ich auch gelegentlich gehabt.
NTFS auf Linux (KNOPPIX) funktioniert meiner Erfahrung nach sehr gut, sogar ausgezeichnet.
Damit kannst du arbeiten und einen Hilfs-Rechner aufsetzen um dann Daten von FreeBSD zu holen (NFS oder ftp) und auf eine externe NTFS-Platte zu bringen.

Verschlüsselungen gibt es viele, ob truecrypt bei Knoppix an Bord ist: k.a.
Einfach rar und Schlüssel? rar ist in den Ports und einer meiner Lieblinge (wenngleich ich den noch nie auf ein Archiv mit +TB angewendet habe, da wird es wohl schon dauern... vielleicht mehrere kleinere Teil-Archive produzieren?). Es gibt rar für alle Plattformen und sollte auch bei Windows kein Problem sein, evtl mit grafischer Oberfläche.

Bei Übertragung auf NTFS werden meiner Erfahrung nach nicht alle Rechte immer ordentlich übernommen, sprich, es gibt manchmal Gemecker. Um das zu verhindern und generell, würde ich zuvor alle Daten-Files 777 setzen. Dann sollte es keine Probleme für den User auf Win-Seite geben.

edit: ich sollte noch nachschieben, dass auch bei dem Knoppix keine direkte Linux-Lösung existiert (wie wohl auch) sondern eine fuse-Implementierung des NTFS genommen wird.
Probleme mit NTFS und FreeBSD(8.3 mit fuse) habe ich allerdings auch nie wirklich gehabt. Knoppix bietet mir einige erweiterte Möglichkeiten direkt und mit grafischen Tools und User-Ready - genau das Passende für die wenigen Gelegenheiten, wo ich das brauche.
G4L (Ghost for Linux) erlaubt sogar komplette Backups von NTFS und auch auf NTFS und es benutzt die gleichen Mechanismen, wie Knoppix. Ich finde Knoppix etwas einfacher zu benutzen. Aber das scheint mir dafür zu sprechen, dass unter Linux keine großen Probleme auftreten (oder ignoriert werden?).
 
Zuletzt bearbeitet:
Wotan schrieb:
Bezieht sich keine Probleme auf Lesen und Schreiben? NTFS Support ist das einzige was ich noch vermisse unter FreeBSD.
Zum Vergrößern anklicken....
Lesen ist kein Problem (nur der Durchsatz ist murksig, bei HD-Videos besser einen GROßEN Cache verwenden). Bestimmte Schreibzugriffe Resetten aber das System. Damit meine ich das ganze System. Man Sitzt einfach plötzlich vor dem BIOS Screen. Gehen sie nicht über Panic, ziehen sie keine Debugging Informationen ein …

Die Probleme gab es auch mit allen anderen Fuse Dateisystemen, man konnte sich die entsprechenden Operationen halt abgewöhnen. Aber seid den NTFS-Verbesserung ist die Situation mit NTFS exakt gleich geblieben. Alle anderen Fuse Systeme funktionieren nun gar nicht mehr. Und einige davon hatte ich wirklich gerne.

@Yamag die Current Version habe ich noch nicht getestet. Es sollte mich wundern, dass das unter 9.x funktioniert. Ich habe den Entwicklern seinerzeit Detailliert geschildert was bei mir alles mit ihren Verbesserungen kaputtging. So ziemlich jeder experimentelle foo wäre meiner Meinung nach sofort zu committen, da es einfach kaum noch schlechter werden kann.
 
Also, der bisherige fusefs-kmod Port setzt auf einem unvollständigen Portierungsversuch einer älteren FUSE-Version von ca. 2007 auf. Das Kernelmodul war extrem buggy, konkret führte es zur Kernelspeicherkorruption. Das ist natürlich extrem kritisch, denn wenn Mist in den RAM gelangt kann es alle möglichen Nebenwirkungen haben. Panic, Triple-Fault wenn z.B. die GDT überschrieben wurde, geschredderte Dateisysteme...Praktisch war FUSE damit nie wirklich nutzbar, es ging halt nur durch eine Menge Hacks so lala. Nun ist eines der Ziele für FreeBSD 10.0 das wirre BSD-VFS aufzuräumen und vor allem deutlich schneller zu machen. Dafür mussten alle noch nicht SMP-fähigen Dateisysteme eliminiert werden, die bekanntesten Namen auf der Liste sind smbfs und NTFS. Also stand man vor der Wahl, diese Dateisysteme neu zu implementieren oder eine andere Lösung zu finden. Man entschied sich für FUSE, da FUSE für solche Sekundärdateisysteme ausreichend schnell ist und man Zugriff auf eine Unmenge Dateisysteme erhält. Daher machte sich Attilio Rao an die Arbeit und räumte zusammen mit George Neville-Neil FUSE auf und portierte es sauber auf FreeBSD. In 10-CURRENT ist daher im Basissystem ein sauberes, bugfreies und daher einwandfrei funktionierendes fuse.ko Kernelmodul enthalten. Damit dieses Kernelmodul getestet werden kann, hat man damals die FUSE-Ports teilweise aktualisiert und wollte dieses neues Kernelmodul vorbehaltlich eines exp-Runs in die Ports bringen. Allerdings gibt es im Moment keine exp-Runs, weshalb blind committen müsste. Da aber Makefile-Änderungen am Framework notwendig sind (keine Ahnung wozu) will man es nicht. Der oben verlinkte Port bringt das neue fuse.ko auf 10-CURRENT, aber eben nicht mehr. Hier läuft es auf meinem 9.1 Desktop einwandfrei, ich habe damit schon größer auf NTFS-Platten rumgeschraddelt. Andere Dateisysteme habe ich bisher nur kurz genutzt, weshalb ich mich hüten werde dazu was zu sagen, was über "sollte besser als bisher gehen" hinausgeht. Lange Rede, kurzer Sinn: Wenn du FUSE braucht, nehme dir 10 Minuten Zeit und backe dir das neue Kernelmodul und baue die fusefs-libs sowie alle Dateisystem-Module neu. Schlechter werden wird es nicht. :)
 
nagut, also ich werde jetzt erstmal die Platte klarmachen, die unter Windows einrichten und dann mit dem neuen Kernelmodul gucken ob ich mit FreeBSD Sachen drauf tun kann, und die unter Windows lesen.

Stay tuned.
 
Also ich hab das neue Modul geladen, extra die Sources installiert, alles nötige gebaut, aber wenn ich die Truecrypt-Partition entschlüsseln will gibt es ein
Code: 
FUSE: strategy: filehandles are closed
Dann hängen die Prozesse, lassen sich nicht killen, dann hängt langsam immer mehr im System und es ist nicht mehr möglich das System ohne Gewalt überhaupt aus zu kriegen.

Fazit: Fail.

Ich werde jetzt nochmal gucken ob einfaches NTFS geht und überlegen, ob ich in den saueren Apfel der Unverschlüselung beiße... Wie vormals schon vermutet, soll die Platte als solche weiter im Einsatz, die Zielperson hat keinen extra Platz um hinundher zu kopieren und zu schlüsseln...
 
Zuletzt bearbeitet:
Ich habe es nun so gemacht:
Linux+tcplay+nfs-3g <---- NFS ---- > FreeBSD
Ich war überrascht DragonFlys TrueCrypt-implementierung da schon zu finden, aber sie funktionierte sehr gut. Auch das überprüfen mit dem offiziellen Treucrypt klappte.

Gesamtfazit 1: Fuse ist in seiner allgemein Form unter FreeBSD noch/wieder kaputt.
Gesamtfazit 2: Kernelseitiger Treucrypt-Support wie bei DfBSD wäre echt cool.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben