Kann VeraCrypt unter Linux dauerhafte Mountpunkte verwenden?

12

Kann VeraCrypt unter Linux dauerhafte Mountpunkte verwenden?


Absolute Pfade für Windows + VeraCrypt + verschlüsselte Volumes

Unter Windows kann ich veracrypt-verschlüsselte Partitionen / Festplatten über ein Batch-Skript bereitstellen, das den von angezeigten Gerätenamen verwendetmountvol.exe . Ein solches Attribut ist sehr nützlich, da ein Neustart zu einer Änderung des relativen Pfads führen kann ( \Device\Harddisk1\Partition3-> Neustart -> \Device\Harddisk3\Partition3).

Mein Batch-Skript für Veracrypt-Volumes unter Windows (Kurzform):

@echo
"C:\Program Files\VeraCrypt\VeraCrypt.exe" /v \\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\ /l z /m label=Encrypted_1 /q
"C:\Program Files\VeraCrypt\VeraCrypt.exe" /v \\?\Volume{yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy}\ /l f /m label=Encrypted_2 /q
[...]
pause


Nur Linux + VeraCrypt + verschlüsselte volumenbezogene Pfade?

Ich habe keine Kenntnis über die Existenz eines parallelen Befehls zu Windows, der /v \\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\für die Linux- Befehlszeile verfügbar ist. Ich habe das (vergebliche) --mount=/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxFlag ausprobiert , da der mountvol.exe Datenträgername (wahrscheinlich) auf der UUID-Nummer basiert (allerdings nicht wahrnehmbar blkid). Die offizielle Veracrypt / Truecrypt-Dokumentation ermöglicht es Linux-Benutzern, nur mit relativen (variablen) Pfaden zu arbeiten ( /dev/sda3-> Neustart -> /dev/sdc3). Aufgrund von Inkonsistenzen müssen die Pfade jedes Mal nach dem Laden des Betriebssystems überprüft werden.

Mein Bash-Skript zum Mounten von Veracrypt-Volumes unter Linux (Kurzform):

#! /bin/bash
#
echo "Encrypted_1" && veracrypt --mount /dev/sdq --slot=12 --verbose && echo "Encrypted_1"
echo "Encrypted_2" && veracrypt --mount /dev/sdz3 --slot=1 --verbose && echo "Encrypted_2"
[...]


Lösung?

Weiß jemand, ob der VeraCrypt-Volume-Speicherort unter Linux absolut beschrieben werden kann?

Wenn dies nicht möglich ist, geben Sie bitte Vorschläge zur Erreichung des gleichen Ziels. (zB: udev? fstab?)

Erratum

mountvol.exeerkennt GUID, nicht UUIDwie oben geschrieben.

Christianus
quelle

Antworten:

7

Ich habe die unten stehende Antwort von David Foerster ausgearbeitet und sie für andere Linux-Benutzer, die sich für das vorgestellte Thema interessieren, aussagekräftiger und klarer gemacht.

Absolute Pfade für Linux + VeraCrypt + verschlüsselte Volumes

Nach meinen Recherchen scheint die Zuordnung des absoluten Pfads zum VeraCrypt-Volume (zumindest derzeit) nicht möglich zu sein ( siehe : Eintrag nach ID und Pfad auf wiki.archlinux.org unter Persistent Block Device Naming ( 1 )).

Linux + VeraCrypt + semi-persistente Blockgeräte-Benennung

Wir können jedoch die semi-persistente Blockgerätebenennung verwenden.

1. Nebenweg

/dev/disk/by-path/hängt vom kürzesten physischen Pfad ( 2 ) ab und ändert sich, wenn der Port des Controllers geschaltet wird ( 3 ).

Geben Sie /dev/disk/by-path/Folgendes ein, um den Deskriptor zu erhalten :

ls -l /dev/disk/by-path/

Sie können die erhaltene Benennung verwenden, um das VeraCrypt-Volume bereitzustellen:

veracrypt --mount /dev/disk/by-path/[by-path] --slot=6 --verbose

/dev/disk/by-path/[by-path] kann den relativen Pfad im Bash-Skript ersetzen:

#! /bin/bash
#
echo "Encrypted_1" && veracrypt --mount /dev/disk/by-path/[by-path1] --slot=12 --verbose && echo "Encrypted_1"
echo "Encrypted_2" && veracrypt --mount /dev/disk/by-path/[by-path2] --slot=1 --verbose && echo "Encrypted_2"
[...]

2. by-id

/dev/disk/by-id/wird gemäß der Seriennummer des Geräts ( 4 ) erstellt. wiki.archlinux.org gibt an, dass /dev/disk/by-id/Hardwareänderungen nicht überlebt werden können, dh ein Szenario, in dem das Gerät an den Port des Controllers angeschlossen ist, der einem anderen Subsystem ausgesetzt ist ( 5 ). access.redhat.com behauptet andererseits, dass /dev/disk/by-id/es beibehalten werden kann, selbst wenn auf das Gerät von verschiedenen Systemen zugegriffen wird ( 6 ). Somit symlinkscheint es im Falle /dev/disk/by-id/einer Anwendung ziemlich stabil zu sein .

Geben Sie /dev/disk/by-id/Folgendes ein, um die Gerätenamen zu erhalten :

ls -l /dev/disk/by-id/

Wenn Sie nun das richtige haben, können Sie damit das VeraCrypt-Volume bereitstellen:

veracrypt --mount /dev/disk/by-id/[id] --slot=6 --verbose

Analog zu dem, was in Absatz 1 erwähnt wurde, /dev/disk/by-id/kann in Bash-Skript verwendet werden:

#! /bin/bash
#
echo "Encrypted_1" && veracrypt --mount /dev/disk/by-id/[id1] --slot=12 --verbose && echo "Encrypted_1"
echo "Encrypted_2" && veracrypt --mount /dev/disk/by-id/[id2] --slot=1 --verbose && echo "Encrypted_2"

Vielleicht ist es für jemanden hilfreich.

Nachtrag

/dev/disk/by-id/ ist nicht stabil genug, um die Korrektur des Montageskripts nach dem Neustart zu vergessen.

Christianus
quelle
3

Leider ist der Zugriff auf die UUIDs und Beschriftungen des Dateisystems in verschlüsselten Containern aufgrund von Verschlüsselung nicht möglich, und TrueCrypt / VeraCrypt-Container enthalten keine eigenen UUIDs oder Beschriftungen (oder zumindest keine, die udev im Gegensatz zu denen von LUKS-Containern kennt).

Es gibt eine weitere ausreichend stabile Kennung für Speichervolumes unter Linux: Festplatten-IDs . Du findest sie in:

/dev/disk/by-id/

Bisher habe ich keine dramatischen Änderungen an den symbolischen Links dort bemerkt, da die Namen von generiert werden

  • udev, dessen grundlegende Speicherkonfiguration sich nicht oft ändert,
  • basierend auf dem Herstellernamen, dem Modellnamen und der Seriennummer, die von der Firmware des Laufwerks gemeldet werden, was sich auch nicht oft ändert.
David Foerster
quelle
Es klappt. Allerdings muss ich die mitgelieferte Lösung gegen Stabilität testen. In der Zwischenzeit habe ich Ihre Antwort in eine Form gebracht, die Sie unten sehen können. Es kann sich herausstellen, dass das Thema auch für andere nützlich ist.
Christianus
/dev/disk/by-id/Methode ist zu instabil für meinen Geschmack. Nach einem Neustart wurden zwei Symlinks geändert. Es wäre schön, wenn Veracrypt wie dm-crypt unterschiedliche externe und interne UUIDs verwenden würde.
Christianus
Seltsam. Ich etwas ändern nie da drin hatte , die mit physischen Laufwerken und begann verwandt war ata-*, scsi-*oder sogar usb-*bis auf 1) die *-part*Suffixe Upgrade nach dem Ändern der Partitionstabelle oder 2) nach einer Freigabe mit größeren Änderungen an udev. Ich habe in der Zwischenzeit Laufwerke ausgesteckt und ausgetauscht, und die Kernelnamen ( sd*) ändern sich in der Regel alle paar Starts.
David Foerster
In meinem Fall ata-*wurde durch usb-*zwei externe HDs von WD ersetzt: WDC WD15NMVW-11AV3S3 und WD Elements 107C (1042).
Christianus
Ist mindestens eines der Präfixe für eines der Laufwerke dauerhaft?
David Foerster
0

Machen Sie vor dem Anschließen Ihres Laufwerks einen Schnappschuss.

$> ll /dev/disk/by-id > ~/before.txt

Wieder nach dem Anschließen Ihres Laufwerks. Und schauen Sie sich den Unterschied an:

$> ll /dev/disk/by-id > ~/after.txt
$> diff ~/before.txt ~/after.txt

Sie sollten sehen (dh auf einem zweiteiligen externen Samsung-Laufwerk)

> [...] usb-Samsung_M2_Portable_D3F12345678FE094-0:0 -> ../../sdd
> [...] usb-Samsung_M2_Portable_D3F12345678FE094-0:0-part1 -> ../../sdd1
> [...] usb-Samsung_M2_Portable_D3F12345678FE094-0:0-part2 -> ../../sdd2

Sagen Sie zum Mounten Partition2 davon /mnt/m(mein Beispiel: mit TrueCrypt-Switches)

veracrypt -t -tc -pPasswordIfYouLike -k "" --protect-hidden=no /dev/disk/by-id/usb-Samsung_M2_Portable_D3F12345678FE094-0:0-part2 /mnt/m

Sie können jetzt das entsprechende Mount-Skript für dieses Laufwerk zuverlässig verwenden, unabhängig davon, an welchen USB-Anschluss oder in welcher Reihenfolge es an andere Laufwerke angeschlossen wurde.


Und für ein richtiges, zuverlässiges Unmount-Skript:

veracrypt -t -d /dev/disk/by-id/usb-Samsung_M2_Portable_D3F12345678FE094-0:0-part2


Stabilität?

Ich verwende dies aus erster Hand monatelang an verschiedenen Dockingstationen an verschiedenen Arbeitsplätzen mit mehreren externen Laufwerken verschiedener Marken. Keine Probleme.

Frank Nocke
quelle