Veracrypt (keine Systemverschlüsselung) unter Linux - Erfahrungen?

Mr.joker

Lt. Commander
Registriert
Mai 2008
Beiträge
1.957
Hey,

ich hatte jetzt schon zweimal den Fall, dass eine unter Linux via Veracrypt gemountetete Fesplatte nach ca. 4-6 Wochen plötzlich leer war!
Es handelt sich dabei "nur" um eine Datenfestplatte, also nicht das Betriebssystem. Die komplette Platte ist von Veracrypt in ext4 formatiert und AES verschlüsselt. Lässt sich wie gesagt mounten, und man kann auch wieder neue Dateien abspeichern, aber alles, was gespeichert war, ist komplett weg.

Zum Glück handelt es sich nur um einen Testlauf in VirtualBox. Die Distribution ist Manjaro KDE. Kann beim ersten Datenverlust aber auch irgendetwas anderes mit KDE gewesen sein (mein damaliger Test ist schon ne Weile her).

Unter Windows nutze ich Veracrypt (früher noch Truecrypt) schon seit vielen Jahren völlig prolbemlos - noch nie einen Ausfall gehabt.

Jetzt frage ich mich, woran es liegen kann, läuft Veracrypt unter Linux vielleicht schlicht nicht so zuverlässig? Oder liegt es an VirtualBox?
So einem unsicheren System würde ich meine Daten dann doch ungern anvertrauen!
Klar, Datensicherung muss man eh betreiben. Aber bisher habe ich das relativ entspannt einmal pro Woche gemacht und/oder nach Bedarf. Aber, so wie das unter Linux aussieht, muss man ja dann wirklich jederzeit (spätestens nach einigen Wochen) damit rechnen, ja sogar davon ausgehen, dass alles weg ist.

Nutzt hier jemand vielleicht schon seit längerem Veracrypt Container/Volumes unter Linux und kann was zur Zuverlässigkeit sagen?
 
Benutze seit Jahren Veracrypt container unter Linux und seit ~3 Jahren unter Manjaro ... nie Probleme gehabt.

Müsste ich raten würde ich sagen du hast mal unglücklich die Entf-Taste erwischt. :mussweg:
 
wieso überhaupt veracrypt wenn du auch einfach dm-crypt benutzen kannst?
 
  • Gefällt mir
Reaktionen: lappenkaese1399 und Skudrinka
Vielleicht teilt sich der Threadersteller den Veracrypt-Container z.B. mit einem Windows-System.
Es gibt also durchaus Szenarien, wo dm-crypt nicht funktioniert. Insofern kann man hier wohl kaum von "grundsätzlich besserer Lösung" sprechen.
 
dagegen spricht, dass der container ext4 formatiert ist. würde zwar theoretisch funktionieren, ergibt aber keinen sinn. wo sollte dm-crypt nicht funktionieren, veracrypt aber schon?
 
0x8100 schrieb:
dagegen spricht, dass der container ext4 formatiert ist.
Ja. Das stimmt. Im folgenden Absatz redet er dann plötzlich von Windows.
Womöglich hatte er die dm-crypt-Geschichte gar nicht auf dem Zettel und hat Veracrypt genommen, weil er es schon kannte.
Das alles aufklären kann aber nur er.
 
andy_m4 schrieb:
...
Womöglich hatte er die dm-crypt-Geschichte gar nicht auf dem Zettel und hat Veracrypt genommen, weil er es schon kannte.
...
So ähnlich! :)

Windows habe ich nur ins Spiel gebracht - wie ich schrieb - weil ich mit Veracrypt unter Windows eben schon jahrelange gute Erfahrungen gemacht habe. Soll heißen, ich kenne Veracrypt bisher eigentlich als absolut fehlerfreies zuverlässiges Programm.
Unter Linux (in VirtualBox): Zweimal innerhalb von einigen Wochen -> Festplatte leer.
Diesen Kontrast wollte ich aufzeigen.

Im o.g. Fall war die Platte wie gesagt ext4 formatiert und sollte auch nur von/in Linux genutzt werden.
Eine Idee im Hintergrund war aber tatsächlich auch, eine Platte übers Netzwerk einzubinden. Gerade für den Übergang von Windows zu Linux könnte das eine Idee sein, dachte ich, um von beiden Systemen auf meine Dateien zugreifen zu können.
In dem Fall könnte ich dann natürlich auch meine bestehende Platte (NTFS formatiert mit Veracrypt Container) nehmen.

Tja, und dm-crypt, LUKS ... hmm, da habe ich auch schon mal testweise ein OpenSuse voll verschlüselt. Nach dem zweiten oder dritten Neustart wollte ich wieder mein Passwort eingeben, aber es wurde plötzlich nicht mehr akzeptiert!
Es war aber kein kompliziertes Passwort, sondern ein ganz einfaches, welches ich immer für meine Testinstallationen in VB nehme. Das hat mir erst mal die Lust an der Systemverschlüsselung genommen!

Inwieweit man mit dm-crypt eine Festplatte (nicht das Betriebssystem) verschlüsseln kann, weiß ich nicht. Muss ich mich dann erst mal schlau machen ...
  • Gibt es da was GUI-basiertes (zum Verschlüsseln und zum Mounten)?
  • Wie verhält sich das, wenn ich den PC in den Standby schicke (ich hätte dann eigentlich gerne, dass ich danach nicht erneut ein Passwort eingeben muss, sondern direkt weiterhin Zugriffs aufs Laufwerk habe)?
  • Kann man das auch irgendwie halbautomatisieren, so dass beim Systemstart schon im Hintergrund gemountet wird und ich nur noch das Passwort eingeben muss?
  • Inwieweit könnte ich eine solche Festplatte dann mit einem anderen Betriebssystem wieder einbinden? (Angenommen ich schrotte mir meine Installation so, dass nichts mehr geht und ich eine Neuinstallation mache.)
Alles Sachen, mit denen ich mich dann erstmal beschäftigen muss ...
 
hier das verschlüsseln einer sd-karte unter mint mit gui. beim zugriff über den dateimanager wird man einfach nach dem passwort gefragt. wenn du von einem live-linux bootest (wenn mal was nicht mehr funktioniert), ist das ebenso.
 

Anhänge

  • create_luks.png
    create_luks.png
    59,5 KB · Aufrufe: 285
  • luks.png
    luks.png
    72,1 KB · Aufrufe: 279
  • luks_mount1.png
    luks_mount1.png
    53,4 KB · Aufrufe: 271
  • luks_mount2.png
    luks_mount2.png
    52,5 KB · Aufrufe: 277
  • Gefällt mir
Reaktionen: netzgestaltung und Mr.joker
Ah, das sieht ja schon mal gut aus! Besonders die Passwort-Optionen gefallen mir.

Und wie verhält es sich beim Systemstart? Poppt dann automatisch ein Fenster auf mit der Aufforderung zur Passworteingabe, bzw. kann man das so oder so ähnlich einrichten?
Jetzt mal vom normalen Betriebssystem ausgegangen (und intern via SATA verbauter SSD), mit dem ich das Volume auch erstellt habe, also nicht eine Live-Installation o.ä.
 
sofern du das passwort nicht dauerhaft speicherst, kommt die abfrage beim ersten zugriff auf den verschlüsselten datenträger.

du kannst das auch automatisch über pam_mount beim login machen lassen.
 
  • Gefällt mir
Reaktionen: Mr.joker
Verwende seit ein paar Jahren Veracrypt für 3 externe Festplatten. Als Dateisystem verwende ich NTFS. Zuerst wurden die Platten unter Windows und Mac genutzt und jetzt hauptsächlich unter Linux (Fedora) und manchmal Windows.

Einmal die Woche wird dabei mit rsync ein Abgleich gemacht.

Bis jetzt kam es dabei noch nie zu Datenverlusst.
 
  • Gefällt mir
Reaktionen: netzgestaltung und Mr.joker
Ob ein Pop up kommt wegen passworteingabe haengt von der "oberfläche" und den config files ab.

persönlich rate ich von ntfs ab.

Ich verwende nur cryptsetup und die commands per shell. Auch empfehle ich das mounten per hand. und ich empfehle ext4
https://linuxwiki.de/cryptsetup

Von irgendwelchen grafischen oberflächen rate ich ab.

ob man seine daten mit windows teilen muss / soll ist out of scope und werde ich hier nicht weiter kommentieren.

bezüglich intern verbauter festplatte, pop up bei anmelden usw, sei auf die /etc/fstab verwiesen, falls dein gnu linux sich an FHS hält.
Ergänzung ()

Mr.joker schrieb:
Tja, und dm-crypt, LUKS ... hmm, da habe ich auch schon mal testweise ein OpenSuse voll verschlüselt. Nach dem zweiten oder dritten Neustart wollte ich wieder mein Passwort eingeben, aber es wurde plötzlich nicht mehr akzeptiert!

man cryptsetup
cryptsetup luksAddKey ....

AFAIK: So weit ich weis kann man bis zu 8 Schlüssel setzen




  • Wie verhält sich das, wenn ich den PC in den Standby schicke (ich hätte dann eigentlich gerne, dass ich danach nicht erneut ein Passwort eingeben muss, sondern direkt weiterhin Zugriffs aufs Laufwerk habe)?
Das ist nicht anzuraten!

  • Kann man das auch irgendwie halbautomatisieren, so dass beim Systemstart schon im Hintergrund gemountet wird und ich nur noch das Passwort eingeben muss?
Stichwort handgeschriebenes Initramfs
 
Zuletzt bearbeitet:
Ich glaube, ich will doch erst mal bei Veracrypt bleiben, da mein System nicht mehr gestartet ist, nachdem ich (in VB) eine neue Festplatte hinzugefügt hatte, diese dann mit der KDE-Partitionsverwaltung in ext4 formatiert und das Häkchen bei LUKS-Verschlüsselung gesetzt hatte. Ich wurde dann aufgefordert, ein Passwort zu vergeben.
Danach hatte ich noch einen Mountpoint in meinem Home-Verzeichnis gesetzt und es dort hin gemountet.
Es schien erst mal ganz einfach zu sein!
Dann konnte ich aber mangels Rechten im neu erstellten Ordner keine Dateien speichern. Wobei die Angaben irgendwie widersprüchlich waren ... eigentlich war ich schon der Eigentümer des Ordners, wenn ich in Dolphin einen Rechtsklick gemacht und dann auf Eigenschaften gegangen bin. Aber anscheinend doch nicht.
Daraufhin habe ich mit
sudo chown -cR Benutzer:Benutzer /home/Benutzer/Verzeichnis
den Eigentümer gewechselt.
Danach konnte ich Dateien abspeichern.

Nach einem Neustart blieb dann der Bildschirm schwarz. Es kamen ein paar Fehlermeldungen, irgendwas von "failed to mount ..." oder so.

Weil ich gestern Abend/Nacht keinen Bock mehr hatte, habe ich das System dann mittels Wiederherstellungspunkt in VirtualBox wieder zurückgesetzt, so dass ich den Fehler heute nicht mehr rekonstruieren kann (könnte ich vermutlich, wenn ich wieder ein Laufwerk mit LUKS verschlüsseln würde (wollte ich später nochmal probieren), aber ich denke, das würde den Rahmen hier wohl sprengen, oder hätte jemand Lust, mir dabei zu helfen? :mussweg:

Offenbar kann man dabei doch schnell große Fehler machen, die dazu führen, dass nichts mehr geht - das halte ich für nicht anfängergerecht!


Daher nochmal zu Veracrypt:
Vielleicht habe ich den zweimaligen Datenverlust, weil ich das Volume meistens nicht manuell aushänge beim Runterfahren. Natürlich speichere und schließe ich sämtliche geöffeten Dateien vorher.
Ich nutze es ja nicht nur, um kurz mal eine Datensicherung zu machen und dann wieder abzuklmemmen, sondern all meine Daten, mit denen ich regelmäßig arbeite, sind da drauf. Deshalb ist es ständig geöffnet/eingehängt und soll nur beim Runterfahren geschlossen werden. (Im Moment simuliere ich das alles ja nur in der virtuellen Maschine.)

Es ist schwer, darüber Informationen zu finden ...
In einem Wiki von Ubuntu steht:
In der Standard-Einstellung werden die Veracrypt-Laufwerke im Standby-Modus (Bereitschaft) und beim Herunterfahren automatisch ausgehängt. Falls man Dateien oder Programme von den verschlüsselten Containern bzw. Laufwerken geöffnet hat, fehlt diesen Dateien beim Aufwecken der Zugriff auf ihren Speicherort.

Zum Deaktivieren des automatischen Aushängens (dismount) während des Bereitschafts-Modus muss die Datei /etc/default/veracrypt mit root-Rechten bearbeitet werden. ...
Aber das ist halt Ubuntu, ich nutze ja Manjaro.
Dass sich das Veracrypt-Laufwerk im Standby automatisch aushängt, stimmt bei mir schon mal nicht.
Und im Verzeichnis /etc/default gibt es bei mir keine Datei namens veracrypt!
Ich könnte sie anlegen und mit den im Artikel beschriebenen Attributen versehen, aber würde Veracrypt darauf zugreifen (wenn es die Datei ja offensichtlich bei der Installation auch nicht von selbst angelegt hat)?
Einen Hinweis, wie Veracrypt konfiguriert ist, habe ich bei mir unter folgendem Pfad gefunden:
/home/Benutzer/.config/VeraCrypt/Configuration.xml
In der Datei steht folgendes:
Code:
<VeraCrypt>
<configuration>
<config key="BackgroundTaskEnabled">1</config>
<config key="BackgroundTaskMenuDismountItemsEnabled">1</config>
<config key="BackgroundTaskMenuMountItemsEnabled">1</config>
<config key="BackgroundTaskMenuOpenItemsEnabled">1</config>
<config key="BeepAfterHotkeyMountDismount">0</config>
<config key="CachePasswords">0</config>
<config key="CloseBackgroundTaskOnNoVolumes">1</config>
<config key="CloseExplorerWindowsOnDismount">1</config>
<config key="CloseSecurityTokenSessionsAfterMount">0</config>
<config key="DisableKernelEncryptionModeWarning">0</config>
<config key="DismountOnInactivity">0</config>
<config key="DismountOnLogOff">1</config>
<config key="DismountOnPowerSaving">0</config>
<config key="DismountOnScreenSaver">0</config>
<config key="DisplayMessageAfterHotkeyDismount">0</config>
<config key="BackgroundTaskEnabled">1</config>
<config key="ForceAutoDismount">1</config>
<config key="LastSelectedSlotNumber">1</config>
<config key="MaxVolumeIdleTime">60</config>
<config key="MountDevicesOnLogon">0</config>
<config key="MountFavoritesOnLogon">0</config>
<config key="MountVolumesReadOnly">0</config>
<config key="MountVolumesRemovable">0</config>
<config key="NoHardwareCrypto">0</config>
<config key="NoKernelCrypto">0</config>
<config key="OpenExplorerWindowAfterMount">0</config>
<config key="PreserveTimestamps">1</config>
<config key="SaveHistory">1</config>
<config key="StartOnLogon">0</config>
<config key="UseKeyfiles">0</config>
<config key="WipeCacheOnAutoDismount">1</config>
<config key="WipeCacheOnClose">0</config>
<config key="DefaultTrueCryptMode">0</config>
<config key="DefaultPRF">autodetection</config>
</configuration>
</VeraCrypt>
Aus den Code-Zeilen
<config key="DismountOnInactivity">0</config>
<config key="DismountOnLogOff">1</config>

könnte ich schließen, dass es zufällig richtig konfiguriert ist (so wie ich es will), nämlich bei Standby eingehängt bleibt, und beim Runterfahren automatisch ausgehängt wird.
Möglicherweise funktioniert das automatische Aushängen (unter Linux) aber trotzdem nicht zuverlässig?
 
Mr.joker schrieb:
Vielleicht habe ich den zweimaligen Datenverlust, weil ich das Volume meistens nicht manuell aushänge beim Runterfahren. Natürlich speichere und schließe ich sämtliche geöffeten Dateien vorher.
Ein Dateisystem sollte immer ausgehängt werden. Das sorgt dafür, das alle Daten tatsächlich geschrieben sind und stellt sicher das sich das Dateisystem in einem konsistenten Zustand befindet.
 
andy_m4 schrieb:
Ein Dateisystem sollte immer ausgehängt werden. ...
Ja, klar, ich bin ja nur davon ausgegangen, dass das System das automatsich macht.
Unter Windows funktioniert das bei mir auch schon seit vielen Jahren zuverlässig.
 
Zurück
Oben