Comment on Trouble automounting a LUKS parition that is on a mdadm raid6

db_geek@norden.social ⁨1⁩ ⁨day⁩ ago

• db_geek@norden.social ⁨1⁩ ⁨day⁩ ago

  Another way can be pam_mount, which I'm using on an SBC for opening an encrypted device:
  https://inai.de/projects/pam_mount/

  original
• Hercules@lemmy.world ⁨1⁩ ⁨day⁩ ago

  :D while your steps were very clear i think i fked up.

  cryptsetup luksAddKey /dev/mapper/raid /etc/crypttab.d/keyfile-data.bin --new-key-slot 1 gave: Device /dev/mapper/raid is not a valid LUKS device.. I assume this is a typo from your end since /dev/md0 is my luks volume. But altering this gave me: slot is already in use kind of error.

  That can be explained since i tested something simular like you suggested earlier. Afterwhich i removed my key i generated and added to the volume. Then i did cryptsetup luksRemoveKey /dev/md0.

  Now when i try to add it i get No key available with this passphrase.

  I don’t have enough knowledge about cryptsetup to know what excactly i did wrong.

  Do you by any change have an explaination?

  In case this is usefull:

  [root@nfs-rocky-1 ~]# cryptsetup luksDump /dev/md0
  LUKS header information
  Version:       	2
  Epoch:         	6
  Metadata area: 	16384 [bytes]
  Keyslots area: 	16744448 [bytes]
  UUID:          	485df758-6cec-49e3-aceb-438aaaedc833
  Label:         	(no label)
  Subsystem:     	(no subsystem)
  Flags:       	(no flags)
  
  Data segments:
    0: crypt
  	offset: 16777216 [bytes]
  	length: (whole device)
  	cipher: aes-xts-plain64
  	sector: 4096 [bytes]
  
  Keyslots:
    1: luks2
  	Key:        512 bits
  	Priority:   normal
  	Cipher:     aes-xts-plain64
  	Cipher key: 512 bits
  	PBKDF:      argon2id
  	Time cost:  4
  	Memory:     1048576
  	Threads:    4
  	Salt:       17 c5 ff 7f b9 10 43 41 16 5a c8 28 44 b9 df 64
  	            a8 1d 40 41 9f a1 70 85 34 06 52 8d ba 29 bd ef
  	AF stripes: 4000
  	AF hash:    sha256
  	Area offset:290816 [bytes]
  	Area length:258048 [bytes]
  	Digest ID:  0
    2: luks2
  	Key:        512 bits
  	Priority:   normal
  	Cipher:     aes-xts-plain64
  	Cipher key: 512 bits
  	PBKDF:      argon2id
  	Time cost:  12
  	Memory:     1048576
  	Threads:    4
  	Salt:       64 97 db 49 f1 18 b9 57 3b 02 53 37 b3 11 8e 44
  	            71 d1 70 b2 b9 58 4c db e2 6b 36 95 7c dd d2 be
  	AF stripes: 4000
  	AF hash:    sha256
  	Area offset:548864 [bytes]
  	Area length:258048 [bytes]
  	Digest ID:  0
  Tokens:
  Digests:
    0: pbkdf2
  	Hash:       sha256
  	Iterations: 105703
  	Salt:       ae ac f1 9f df 47 27 9e 64 28 52 53 9a 9b cd 77
  	            74 15 66 f6 8b 3c bd f4 29 dc f1 b1 c5 15 3b f6
  	Digest:     07 5f 2f 6b d3 c5 bf b6 54 58 5e b4 44 df 8c b8
  	            2b da fa 5c 40 a5 89 cc 0e 3b 70 69 57 d5 7c f5
  [root@nfs-rocky-1 ~]#
  

  original

  • db_geek@norden.social ⁨1⁩ ⁨day⁩ ago

    @Hercules My exampled assumed, that you only have a password set on keyslot 0.

    LUKS keyslots are starting at 0, so it seems, that you deleted the initial set password.
    I hope, you know the other keyslots.

    As far I can see, you can specify, which keyslot has to be selected for unlocking the volume key.
    More information you can find in the man page.
    ```
    man cryptsetup-luksaddkey

    cryptsetup luksAddKey /dev/md0 --new-key-slot 0 --key-slot 1
    ```

    original

    • Hercules@lemmy.world ⁨1⁩ ⁨day⁩ ago

      Just to give you an update. The other keyslot was the key i added earlier for testing which i removed … So its time for me to copy over a lot of data to another system en recreate the luks volume. Thanks for your help!

      original

      • db_geek@norden.social ⁨15⁩ ⁨hours⁩ ago

        @Hercules So it was possible to use one of the other keyslots to open the encryption?

        Probably you can test your wanted configuration in a virtual machine with some small virtual drives to avoid any loss of data.
        I found it relative difficult to find the correct UUID which had to be used when I setup my system in the past.

        original

        • -> View More Comments
• Hercules@lemmy.world ⁨1⁩ ⁨day⁩ ago

  Is the /etc/crypttab.d path that you are using specificly chosen or can it be whatever? This path doesn’t exists on my system online i don’t see any mentions of it.

  original

  • db_geek@norden.social ⁨1⁩ ⁨day⁩ ago

    @Hercules I created it on my own, because I have some keys for other devices, too.
    But you can place it, where you want.
    But with crypttab.d I have a simple connection to crypttab configuration file.

    original
  • nublug@piefed.blahaj.zone ⁨1⁩ ⁨day⁩ ago

    the crypttab.d thing is called a drop-in directory. linux will read files you make in these and overwrite the config files with the values in the drop-in files. it’s a way to add your own edits to config files without editing the default config files directly, so you don’t have to say manually copy crypttab to crypttab.old for a backup and instead always have a default config to fall back to if things go wrong by just commenting out your few changes in the drop-in file.

    original
• Hercules@lemmy.world ⁨1⁩ ⁨day⁩ ago

  Thanks for your response!

  I will give it a try. Have a great rest of your day!

  original