VeraCrypt peut-il utiliser des points de montage persistants sous Linux?

Windows + VeraCrypt + chemins absolus de volume chiffré

Sous Windows, je peux monter des partitions / disques cryptés veracrypt via un script batch qui utilise le nom du périphérique affiché par mountvol.exe. Un tel attribut est très utile car le redémarrage peut entraîner une altération du chemin relatif ( \Device\Harddisk1\Partition3-> reboot -> \Device\Harddisk3\Partition3).

Mon script batch pour les volumes veracrypt sous Windows (forme abrégée):

@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 + chemins relatifs des volumes chiffrés uniquement?

Je n'ai aucune connaissance de l'existence d'une commande parallèle à Windows disponible /v \\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\pour la ligne de commande Linux. J'ai essayé (en vain) le --mount=/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxdrapeau, car le mountvol.exe nom du volume est (probablement) basé sur le numéro UUID (imperceptible blkidcependant). La documentation officielle de veracrypt / truecrypt permet aux utilisateurs Linux de fonctionner uniquement avec des chemins relatifs (variables) ( /dev/sda3-> reboot -> /dev/sdc3). En raison de l'inconstance, les chemins doivent être vérifiés à chaque fois après le chargement du système d'exploitation.

Mon script bash pour monter des volumes veracrypt sur Linux (forme abrégée):

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

Solution?

Est-ce que quelqu'un sait si l'emplacement du volume VeraCrypt peut être décrit en termes absolus sous Linux?

Si ce n'est pas possible, veuillez fournir des suggestions pour atteindre le même objectif. (par exemple: udev? fstab?)

Erratum

mountvol.exereconnaît GUID, pas UUIDcomme il a été écrit ci-dessus.

— Christianus
source

Réponses:

J'ai développé la réponse ci-dessous publiée par David Foerster et l' ai rendue plus descriptive et claire pour les autres utilisateurs Linux intéressés par le sujet présenté.

Chemins absolus de volume chiffré Linux + VeraCrypt +

Selon mes recherches, il semble que l'attribution d'un chemin absolu au volume VeraCrypt soit impossible (au moins actuellement) ( vide : entrée par id et par chemin sur wiki.archlinux.org sous la dénomination persistante des périphériques de bloc ( 1 )).

Nommage de périphérique de bloc semi-persistant Linux + VeraCrypt +

Cependant, nous pouvons utiliser un nom de périphérique de bloc semi-persistant.

1. par chemin

/dev/disk/by-path/dépend du chemin physique le plus court ( 2 ) et change lorsque le port du contrôleur est commuté ( 3 ).

Pour obtenir le /dev/disk/by-path/descripteur, tapez:

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

Vous pouvez utiliser la dénomination obtenue pour monter le volume VeraCrypt:

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

/dev/disk/by-path/[by-path] peut remplacer le chemin relatif dans le script 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/est créé selon le numéro de série de l'appareil ( 4 ). wiki.archlinux.org déclare qu'il /dev/disk/by-id/ne peut pas survivre à des changements matériels, c'est-à-dire un scénario où le périphérique est branché sur le port du contrôleur soumis à un sous-système différent ( 5 ). access.redhat.com , d'autre part, affirme que cela /dev/disk/by-id/peut être maintenu même si l'appareil est accessible par différents systèmes ( 6 ). Ainsi, symlinksemble être assez stable en cas d' /dev/disk/by-id/application.

Pour obtenir le /dev/disk/by-id/nom du périphérique, tapez:

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

Maintenant, lorsque vous en avez un correct, il peut être utilisé pour monter le volume VeraCrypt:

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

De façon similaire à ce qui a été noté dans le paragraphe un, /dev/disk/by-id/peut être utilisé dans le script 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"

Ce sera peut-être utile pour quelqu'un.

Addenda

/dev/disk/by-id/ n'est pas assez stable pour oublier de corriger le script de montage après le redémarrage.

— Christianus
source

Malheureusement, les UUID et les étiquettes du système de fichiers à l'intérieur des conteneurs chiffrés sont inaccessibles en raison du chiffrement et les conteneurs TrueCrypt / VeraCrypt ne portent pas les UUID ou les étiquettes par eux-mêmes (ou du moins aucun que udev ne connaît par opposition à ceux des conteneurs LUKS).

Il existe un autre identifiant suffisamment stable pour les volumes de stockage sous Linux: les ID de disque . Vous pouvez les trouver dans:

/dev/disk/by-id/

Jusqu'à présent, je n'ai jamais remarqué de changements spectaculaires dans les liens symboliques, car les noms sont générés par

udev, dont la configuration de stockage de base ne change pas souvent,
basé sur le nom du fabricant, le nom du modèle et le numéro de série indiqué par le micrologiciel du lecteur, qui ne change pas souvent non plus.

— David Foerster
source

Ça marche. Cependant, je dois tester la solution fournie contre la stabilité. En attendant, j'ai développé votre réponse sous une forme que vous pouvez voir ci-dessous. Il se peut que ce sujet soit également utile à quelqu'un d'autre.

— Christianus

/dev/disk/by-id/la méthode est trop instable à mon goût. Après un redémarrage, deux liens symboliques ont changé. Ce serait bien si veracrypt utilisé, comme dm-crypt, différents UUID externes et internes.

— Christianus

Impair. Je n'ai jamais rien changé là-dedans qui était lié aux disques physiques et j'ai commencé avec ata-*, scsi-*ou même à l' usb-*exception de 1) les *-part*suffixes après avoir changé la table de partition ou 2) après une mise à niveau de la version, y compris des modifications majeures d'udev. J'ai débranché et échangé des disques entre-temps et les noms du noyau ( sd*) ont tendance à changer à chaque démarrage.

— David Foerster

Dans mon cas, a ata-*été remplacé par usb-*deux disques durs externes fabriqués par WD: WDC WD15NMVW-11AV3S3 et WD Elements 107C (1042).

— Christianus

Au moins l'un des préfixes persiste-t-il pour l'un des lecteurs?

— David Foerster

Avant de connecter votre lecteur, prenez un «instantané»

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

Encore une fois, après avoir connecté votre lecteur. Et regardez le diff:

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

Vous devriez voir (c'est-à-dire sur un disque Samsung externe en deux parties)

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

Pour monter, disons partition2 de celui-ci /mnt/m(mon exemple: avec les commutateurs truecrypt)

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

Vous pouvez désormais utiliser de manière fiable le script de montage correspondant à ce lecteur, quel que soit le port USB ou l'ordre dans lequel il est connecté aux autres lecteurs.

Et pour un script de démontage correct et fiable:

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

stabilité?

J'utilise cette première main sur diverses stations d'accueil, dans divers lieux de travail avec plusieurs disques externes de différentes marques depuis des mois. Pas de problème.

— Frank Nocke
source