Red Hat Enterprise Linux Diagnostics and Troubleshooting

Instructions

A LUKS-encrypted volume that is mounted at /mnt/secure on servera was protected by the password R3dH@t123. After a routine change, an administrator changed the password to newP@ss321. Unfortunately, the administrator now reports that the new password does not work on the encrypted volume. A recent backup of the volume's LUKS header is available at /root/luks_header_backup. Assess the situation and restore the volume to working order. If needed, use the LUKS header backup to restore the encrypted volume's function.

1. Log in to servera and switch to the root user.

   [student@workstation ~]$ ssh student@servera
   ...output omitted...
   [student@servera ~]$ sudo -i
   [sudo] password for student: student
   [root@servera ~]#

2. Determine the system's encrypted volume configuration.

   1. View /etc/fstab to determine the volume that is configured to mount at /mnt/secure.

      [root@servera ~]# grep /mnt/secure /etc/fstab
      /dev/mapper/secure     /mnt/secure     xfs     defaults     1 2

   2. View /etc/crypttab to determine how encrypted devices are set up on the system at boot time.

      [root@servera ~]# cat /etc/crypttab
      secure /dev/vdb1 none

3. Assess the current state of the encrypted volume. Use the dmsetup command to determine whether a mapped device exists for the encrypted block device. Use the --target crypt subcommand to filter for an encrypted block device.

   [root@servera ~]# dmsetup ls --target crypt
   No devices found

4. Because the mapped device does not exist, use the cryptsetup luksOpen command to manually open the encrypted volume and create the associated mapped device that is specified in /etc/crypttab. Try decrypting the encrypted volume with the new password that the previous administrator set. If that password does not work, then try the old password.

   [root@servera ~]# cryptsetup luksOpen /dev/vdb1 secure
   Enter passphrase for /dev/vdb1: newP@ss321
   No key available with this passphrase.
   Enter passphrase for /dev/vdb1: R3dH@t123
   No key available with this passphrase.
   Enter passphrase for /dev/vdb1: R3dH@t123
   No key available with this passphrase.

5. Use the cryptsetup luksDump command to determine whether the encrypted volume has other key slots.

   [root@servera ~]# cryptsetup luksDump /dev/vdb1
   LUKS header information
   Version:       	2
   Epoch:         	5
   Metadata area: 	16384 [bytes]
   Keyslots area: 	16744448 [bytes]
   UUID:          	d132238a-6eb7-4025-9ea0-2a77837aa755
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	  (no flags)
   
   Data segments:
     0: crypt
   	offset: 16777216 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 512 [bytes]
   
   Keyslots:
     1: luks2
   	Key:        512 bits
   	Priority:   normal
   	Cipher:     aes-xts-plain64
   	Cipher key: 512 bits
   	PBKDF:      argon2i
   	Time cost:  4
   	Memory:     930312
   	Threads:    2
   	Salt:       14 01 41 d5 1f de 0f 3c 3a 95 05 9e bc 61 00 d8
   	            c9 a3 e7 87 09 ab c1 dd 02 45 fc 28 a9 71 f3 0e
   	AF stripes: 4000
   	AF hash:    sha256
   	Area offset:290816 [bytes]
   	Area length:258048 [bytes]
   	Digest ID:  0
   Tokens:
   Digests:
     0: pbkdf2
   	Hash:       sha256
   	Iterations: 112604
   	Salt:       ff 16 a5 6c 70 4a 6f 51 ed 84 53 2a ef 24 5d 52
   	            cb 0a 51 18 3d c3 e4 95 54 01 10 b3 24 32 42 bb
   	Digest:     69 ba fe 4e 19 70 37 c4 9a ba 01 10 fe 35 18 f2
   	            9e b8 ed e6 5d e3 bd b5 3f 17 60 2e a1 67 51 d7

   The volume does not have any other keys.

6. Because no known passwords or other keys are available in the volume, the remaining option is to reinstate the old password by restoring the LUKS header from the /root/luks_header_backup backup file.

   1. As a recommended step to reverse live mistakes, back up the current LUKS header before replacing it with the backup LUKS header.

      [root@servera ~]# cryptsetup luksHeaderBackup /dev/vdb1 --header-backup-file /root/luks_header_new

   2. Restore the old LUKS header from the /root/luks_header_backup file to reinstate the old password.

      [root@servera ~]# cryptsetup luksHeaderRestore /dev/vdb1 --header-backup-file /root/luks_header_backup
      
      WARNING!
      ========
      Device /dev/vdb1 already contains LUKS header. Replacing header will destroy existing keyslots.
      
      Are you sure? (Type uppercase yes): YES

7. Use the cryptsetup luksOpen command to manually open the encrypted volume and create the associated mapped device in the /etc/crypttab file. Try decrypting the encrypted volume with the old password.

   [root@servera ~]# cryptsetup luksOpen /dev/vdb1 secure
   Enter passphrase for /dev/vdb1: R3dH@t123

8. Use the dmsetup command to validate that the secure mapped device name now exists for the encrypted block device. Use the --target crypt subcommand to filter for encrypted block devices only.

   [root@servera ~]# dmsetup ls --target crypt
   secure  (253, 0)

9. Verify that the mapped device for the encrypted volume can be successfully mounted at /mnt/secure.

   [root@servera ~]# mount /mnt/secure
   [root@servera ~]# mount | grep /mnt/secure
   /dev/mapper/secure on /mnt/secure type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

10. Return to workstation as the student user.

    [root@servera ~]# exit
    [student@servera ~]$ exit
    [student@workstation ~]$