Czy VeraCrypt może używać trwałych punktów montowania w systemie Linux?

12

Czy VeraCrypt może używać trwałych punktów montowania w systemie Linux?


Windows + VeraCrypt + absolutne ścieżki zaszyfrowanego woluminu

W systemie Windows mogę montować zaszyfrowane partycje / dyski veracrypt za pomocą skryptu wsadowego, który wykorzystuje wyświetlaną nazwę urządzeniamountvol.exe . Taki atrybut jest bardzo przydatny, ponieważ ponowne uruchomienie może prowadzić do zmiany ścieżki względnej ( \Device\Harddisk1\Partition3-> restart -> \Device\Harddisk3\Partition3).

Mój skrypt wsadowy dla woluminów veracrypt w systemie Windows (skrócona forma):

@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


Linux + VeraCrypt + tylko ścieżki względne zaszyfrowanego woluminu?

Nie mam wiedzy na temat istnienia polecenia równoległego do systemu Windows /v \\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\dostępnego dla wiersza poleceń systemu Linux. Próbowałem (na próżno) --mount=/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxflagę, ponieważ mountvol.exe nazwa woluminu jest (prawdopodobnie) oparta na numerze UUID ( blkidchoć niezauważalny ). Oficjalna dokumentacja veracrypt / truecrypt pozwala użytkownikowi Linuxa działać tylko ze względnymi (zmiennymi) ścieżkami ( /dev/sda3-> restart -> /dev/sdc3). Z powodu niestałości ścieżki muszą być weryfikowane za każdym razem po załadowaniu systemu operacyjnego.

Mój skrypt bash do montowania woluminów veracrypt w systemie Linux (skrócona forma):

#! /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"
[...]


Rozwiązanie?

Czy ktoś wie, czy lokalizację wolumenu VeraCrypt można opisać w systemie Linux bezwzględnie?

Jeśli nie jest to możliwe, proszę podać sugestie dotyczące osiągnięcia tego samego celu? (np: udev? fstab?)

Errata

mountvol.exerozpoznaje GUID, nie UUIDtak jak napisano powyżej.

Christianus
źródło

Odpowiedzi:

7

Poniżej opracowałem odpowiedź wysłaną przez Davida Foerstera i uczyniłem ją bardziej opisową i zrozumiałą dla innych użytkowników Linuksa zainteresowanych przedstawionym tematem.

Linux + VeraCrypt + absolutne ścieżki zaszyfrowanego woluminu

Według moich badań wydaje się, że przypisanie bezwzględnej ścieżki do woluminu VeraCrypt jest niemożliwe (przynajmniej obecnie) ( vide : by-id i by-path entry na wiki.archlinux.org w sekcji Trwałe nazwy urządzeń blokowych ( 1 )).

Linux + VeraCrypt + półtrwałe nazewnictwo urządzeń blokowych

Możemy jednak zastosować półtrwałe nazewnictwo urządzeń blokowych.

1. ścieżka boczna

/dev/disk/by-path/zależy od najkrótszej ścieżki fizycznej ( 2 ) i zmian w miarę przełączania portu kontrolera ( 3 ).

Aby uzyskać /dev/disk/by-path/deskryptor, wpisz:

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

Możesz użyć uzyskanej nazwy do zamontowania woluminu VeraCrypt:

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

/dev/disk/by-path/[by-path] może zastąpić ścieżkę względną w skrypcie bash:

#! /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/jest tworzony zgodnie z numerem seryjnym urządzenia ( 4 ). wiki.archlinux.org stwierdza, że /dev/disk/by-id/nie jest w stanie przetrwać zmian sprzętowych, tj. scenariusz, w którym urządzenie jest podłączone do portu kontrolera poddanego innemu podsystemowi ( 5 ). access.redhat.com , z drugiej strony, twierdzi, że /dev/disk/by-id/można je utrzymać, nawet jeśli do urządzenia mają dostęp różne systemy ( 6 ). Tak więc symlinkwydaje się być dość stabilny w przypadku /dev/disk/by-id/zastosowania.

Aby uzyskać /dev/disk/by-id/nazwę urządzenia, wpisz:

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

Teraz, gdy masz poprawny, można go użyć do zamontowania woluminu VeraCrypt:

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

Analogicznie do tego, co wspomniano w akapicie pierwszym, /dev/disk/by-id/można go użyć w skrypcie bash:

#! /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"

Może komuś się przyda.

Uzupełnienie

/dev/disk/by-id/ nie jest wystarczająco stabilny, aby zapomnieć o poprawieniu skryptu montowania po ponownym uruchomieniu.

Christianus
źródło
3

Niestety identyfikatory UUID i etykiety systemu plików wewnątrz zaszyfrowanych kontenerów są niedostępne z powodu szyfrowania, a kontenery TrueCrypt / VeraCrypt nie niosą samodzielnie identyfikatorów UUID lub etykiet (lub przynajmniej takich, o których udev nie wie, w przeciwieństwie do kontenerów LUKS).

Jest jeszcze jeden wystarczająco stabilny identyfikator woluminów pamięci w systemie Linux: identyfikatory dysków . Można je znaleźć w:

/dev/disk/by-id/

Do tej pory nigdy nie zauważyłem żadnych dramatycznych zmian w symbolicznych linkach, ponieważ nazwy są generowane przez

  • udev, którego podstawowa konfiguracja pamięci nie zmienia się często,
  • na podstawie nazwy producenta, nazwy modelu i numeru seryjnego zgłoszonego przez oprogramowanie układowe napędu, który również nie zmienia się często.
David Foerster
źródło
To działa. Muszę jednak przetestować dostarczone rozwiązanie pod kątem stabilności. Tymczasem rozwinąłem twoją odpowiedź w formę, którą możesz zobaczyć poniżej. Może się okazać, że przedmiot jest przydatny także dla kogoś innego.
Christianus
/dev/disk/by-id/metoda jest zbyt niestabilna jak na mój gust. Po ponownym uruchomieniu zmieniły się dwa dowiązania symboliczne. Byłoby miło, gdyby używał veracrypt, jak dm-crypt, inny zewnętrzny i wewnętrzny UUID.
Christianus
Dziwny. Nigdy nie miałem tam żadnych zmian, które byłyby związane z dyskami fizycznymi i zacząłem od ata-*, scsi-*lub nawet usb-*z wyjątkiem 1) *-part*sufiksów po zmianie tabeli partycji lub 2) po aktualizacji wydania, w tym głównych zmian w udev. W międzyczasie odłączyłem dyski i wymieniłem dyski, a nazwy jądra ( sd*) zmieniają się co kilka rozruchów.
David Foerster,
W moim przypadku ata-*został zastąpiony usb-*dwoma zewnętrznymi dyskami twardymi wykonanymi przez WD: WDC WD15NMVW-11AV3S3 i WD Elements 107C (1042).
Christianus
Czy przynajmniej jeden z prefiksów jest trwały dla jednego z dysków?
David Foerster,
0

Przed podłączeniem dysku wykonaj „migawkę”

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

Ponownie po podłączeniu dysku. I spójrz na różnicę:

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

Powinieneś zobaczyć (tj. Na dwuczęściowym zewnętrznym napędzie Samsung)

> [...] 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

Aby zamontować, powiedz na partycję2 tego /mnt/m(mój przykład: z przełącznikami truecrypt)

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

Teraz możesz niezawodnie używać odpowiedniego skryptu montowania dla tego napędu, bez względu na port USB lub kolejność odpowiadającą innym napędom, do których został podłączony.


A dla prawidłowego, niezawodnego odmontowania skryptu:

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


stabilność?

Używam tego z pierwszej ręki na różnych stacjach dokujących, w różnych miejscach pracy z kilkoma zewnętrznymi dyskami różnych marek od miesięcy. Bez problemów.

Frank Nocke
źródło