You're inserting an already encrypted harddisk into your notebook as a second device assuming you know the password to decrypt your container 
. You won't enter the password for the second harddisk anymore? Then it's time to do some modifications for an automatically mount process. For a new and not encrypted harddisk, please read this post.
CRASH SUMMARY
Below a list of the commands in the right order as a "preview".
cryptsetup luksOpen /dev/sdb1 b69d928c-4eee-456f-b34e-ed8e261f3727
ll /dev/mapper
dmsetup rename b69d928c-4eee-456f-b34e-ed8e261f3727 s120gb
blkid -o list -w /dev/null |grep s120
mkdir /home/dswt/s120dir
cryptsetup luksDump /dev/sdb1
dd if=/dev/urandom of=/root/keys120gb bs=1024 count=2
chmod 400 /root/keys120gb
cryptsetup luksAddKey /dev/sdb1 /root/keys120gb
cryptsetup luksAddKey /dev/sdb1 --key-slot 6
blkid
vim /etc/crypttab
vim /etc/fstab
mount -a
blkid -o list -w /dev/null
dd if=/dev/sda of=mbrsda.img bs=512 count=1 && file mbrsda.img
cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file s120header
cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file s120header
First determine your harddrive to be sure that it isn't mounted already. Otherwise you have to umount it before go forward. Use the command 'blkid -o list -w /dev/null' to see your devices.
...
/dev/sda2 crypto_LUKS (in use) e6f979cf-82f3-4889-a382-09377a2ca0a0
/dev/sdb1 crypto_LUKS (not mounted) b69d928c-4eee-456f-b34e-ed8e261f3727
...
We got two encrypted containers, one is use, the other seems to be our inserted harddisk. To open the container we use 'cryptsetup luksOpen [dev] [UUID]' and the known password.
luksOpen
Enter passphrase for /dev/sdb1:
After opening the container an additional appropriate mapper entry appears. In this example we could recognize also the label 'sam120'. So there is an UUID for the container and an UUID for the underlying filesystem.
...
/dev/sdb1 crypto_LUKS (in use) b69d928c-4eee-456f-b34e-ed8e261f3727
/dev/mapper/b69d928c-4eee-456f-b34e-ed8e261f3727 ext4 sam120 (not mounted) 2da90fb5-6978-4310-8436-5989055d5e10
...
How assigned the device mapper the container and what's the device mapper name for /dev/sdb1?
36146 0 lrwxrwxrwx. 1 root root 7 Apr 7 12:24 b69d928c-4eee-456f-b34e-ed8e261f3727 -> ../dm-5
Rename the device mapper name
The mapper name b69d928c-4eee-456f-b34e-ed8e261f3727 isn't really human friendly. We could change the device mapper name using the command 'dmsetup'. Instead of b69d..... we choose for example s120gb.
Verify if the device mapper name has been changed.
/dev/mapper/s120gb ext4 sam120 (not mounted) 2da90fb5-6978-4310-8436-5989055d5e10
Create a mountpoint
Where do I'd like to mount the second harddisk? I prefer a location within my home directory named s120dir for example.
Check the number of passphrases/keys
Did you know that a LUKS container is able to hold 8 different passphrases/keys, organized from key slot 0 to key slot 7?
To check how many and which key slots are used entry the command 'cryptsetup luksDump /dev/sdb1'.
In our example below we only got one slot occupied: Key Slot 0: ENABLED. The assigned UUID and the strength of the key from the container are listed too.
LUKS header information for /dev/sdb1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: be 1d e5 1a d4 75 d3 06 ce b1 04 09 ce 1a f1 d8 21 56 8f 4b
MK salt: db d7 be 04 09 ed 73 2a 1c 34 06 5b 24 c2 36 8b
26 ef d7 c8 f9 1f 6a 42 b2 9f 8a 23 43 e6 33 52
MK iterations: 41750
UUID: b69d928c-4eee-456f-b34e-ed8e261f3727
Key Slot 0: ENABLED
Iterations: 167311
Salt: 18 f0 3c 9f 0d e8 52 56 51 18 6e 05 89 05 d4 6f
b0 dc da f8 03 fc ab 36 14 a0 57 49 bf 98 7f 3a
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Create a random keyfile
For the automatically mounting of the encrypted harddisk we have to create a random keyfile. The strength of the keyfile is controllable by the options 'bs' and/or 'count' - the higher the values the stronger the key. After creating the keyfile we make it readable only for root using the command 'chmod '. The name of the keyfile in this case is keys120gb.
2+0 records in
2+0 records out
2048 bytes (2.0 kB) copied, 0.000381466 s, 5.4 MB/s[root@localhost ~]# chmod 400 /root/keys120gb
Assign the keyfile to the container: luksAddKey
After creating, saving and protecting the keyfile keys120gb we have to assign it to the container on /dev/sdb1.
Version: 1 Key Slot 0: ENABLED
Enter any passphrase:[root@localhost ~]# cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: be 1d e5 1a d4 75 d3 06 ce b1 04 09 ce 1a f1 d8 21 56 8f 4b
MK salt: db d7 be 04 09 ed 73 2a 1c 34 06 5b 24 c2 36 8b
26 ef d7 c8 f9 1f 6a 42 b2 9f 8a 23 43 e6 33 52
MK iterations: 41750
UUID: b69d928c-4eee-456f-b34e-ed8e261f3727
Iterations: 167311
Salt: 18 f0 3c 9f 0d e8 52 56 51 18 6e 05 89 05 d4 6f
b0 dc da f8 03 fc ab 36 14 a0 57 49 bf 98 7f 3a
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 172917
Salt: e0 f7 13 67 7e bd 91 d8 10 87 61 2f 54 46 53 30
cb 00 83 52 4e 40 f9 82 ed c6 e3 3d 6b 65 4c 1f
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Optional: Create an additional passphrase
To add just an additional passphrase we use the same command but change the options.
We could determine in which key-slot the passphrase will be stored.
After adding the passphrase check the status again.
In the following example I'm adding a new passphrase to another block device - an usb stick. Of course you also could do this with your encrypted harddisk.
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
root@9.164.22.132 ~ # cryptsetup luksDump /dev/sdc1
LUKS header information for /dev/sdc1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 26 3e 3d 94 32 14 9b 38 1a 39 13 82 a1 50 58 84 b0 39 09 5e
MK salt: 57 a0 78 bc 20 d4 08 c6 1b 9b 3e 32 67 f4 e5 90
fa f5 6a 83 dd 3c a3 eb b8 fd 60 e3 2e 81 b1 19
MK iterations: 41500
UUID: 1a6c0abb-e040-4902-8223-ec77ae43db6e
Key Slot 0: ENABLED
Iterations: 166344
Salt: 85 a7 63 b6 cb 85 bf 8c 3d fe 70 70 77 ef 86 ff
0b 01 4d a1 1d 19 1a 00 5d 0b cf 9c 9d f6 7d 9d
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 167911
Salt: c5 c8 7a b5 1d 45 aa 6c 7c 83 88 1d 85 31 29 44
4f 2c da 8e fe 81 b9 e6 07 5b 84 f0 11 6c aa 68
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: ENABLED
Iterations: 162890
Salt: 9c 25 b4 24 ee a5 23 33 97 5a 8c 3c a8 27 d3 56
74 0f ac 7c 9b ce 3d ae c7 46 41 e9 6d a8 bf 7d
Key material offset: 1544
AF stripes: 4000
Key Slot 7: DISABLED
.
To automatically mount the new harddisk '/dev/sdb1' we've to make an entry in '/etc/crypttab' and '/etc/fstab'.
For the entry in fstab we need the UUID from the mapped device 's120gb' we renamed before, UUID="2da90fb5-6978-4310-8436-5989055d5e10" TYPE="ext4" or just the appropriate device mapper name 's120gb'!
Create or modify the file /etc/cryptsetup
For the entry in crypttab we need the UUID from the container /dev/sdb1 -> UUID="b69d928c-4eee-456f-b34e-ed8e261f3727" TYPE="crypto_LUKS".
The command 'blkid' is providing the information:
...
/dev/sda1: UUID="48264761-9202-40e0-904b-181eaab4f513" TYPE="ext2"
/dev/sda2: UUID="e6f979cf-82f3-4889-a382-09377a2ca0a0" TYPE="crypto_LUKS"
/dev/sdb1: UUID="b69d928c-4eee-456f-b34e-ed8e261f3727" TYPE="crypto_LUKS"
...
/dev/mapper/s120gb: LABEL="sam120" UUID="2da90fb5-6978-4310-8436-5989055d5e10" TYPE="ext4"
...
luks-e6f979cf-82f3-4889-a382-09377a2ca0a0 UUID=e6f979cf-82f3-4889-a382-09377a2ca0a0 none
s120gb UUID=b69d928c-4eee-456f-b34e-ed8e261f3727 /root/keys120gb luks
Modify the file /etc/fstab
Finally make an entry in the file /etc/fstab. This time we need the UUID of the underlying filesystem of the container! The commands 'blkid' or 'll /dev/mapper' are providing this information. Please, make the entry using the right UUID, not the device name! So you can avoid a mistaken identity between devices during the boot process.
# /etc/fstab
# Created by anaconda on Fri Apr 5 09:47:04 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vgcent64-lvroot / ext4 defaults 1 1
...
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/disk/by-uuid/2da90fb5-6978-4310-8436-5989055d5e10 /home/dswt/s120dir ext4 defaults 0 0
Mount the new harddisk and give the permissions
To work with the new harddisk we mount it to the created directory '/home/dswt/s120dir' and assign it to the appropriate user - here 'dswt'. The next time you boot the machine the second harddisk will be mounted automatically.
[root@localhost ~]# chown -R dswt:dswt /home/dswt/s120dir/
Let's check the current status now regarding our /dev/sdb1 using the 'blkid' command again:
...
/dev/sdb1 crypto_LUKS (in use) b69d928c-4eee-456f-b34e-ed8e261f3727
...
/dev/mapper/s120gb ext4 sam120 /home/dswt/s120dir
Save the MBR
After a successful reboot it's recommended to save the MBR (Master Boot Record). See also this post.
1+0 records in
1+0 records out
512 bytes (512 B) copied, 4.5068e-05 s, 11.4 MB/s
mbrsda.img: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0xa0800, GRUB version 0.94; partition 1: ID=0x83, active, starthead 32, startsector 2048, 1048576 sectors; partition 2: ID=0x83, starthead 101, startsector 1050624, 624091136 sectors, code offset 0x48
Save the LUKS header
And yes, it's a good idea to backup the header of our LUKS.
[root@localhost ~]# cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file rootheader
To restore the LUKS header from '/dev/sdb1' entry:
WARNING!
========
Device /dev/sdb1 already contains LUKS header. Replacing header will destroy existing keyslots.
Are you sure? (Type uppercase yes): YES
The post Good LUKS: Automatically mount a second LUKS harddrive appeared first on Linux on the mainframe.