3

I've followed this question https://unix.stackexchange.com/questions/5017/ssh-to-decrypt-encrypted-lvm-during-headless-server-boot and successfully remotely decrypted my root drive. However, I have a second drive that I also have encrpted, and unfortunately dropbear is killed by the boot process before second passphrase prompt for the second drive is shown and the main open-ssh server has not yet started so once again the headless system sits waiting for input indefinitely.

Is there any way round this?

The second drive will be used for private cloud data storage so needs to be encrypted to protect the data, and needs to be decrypted before the cloud service starts (which I haven't chosen or installed yet).

Ubuntu 13.10 x64 server running headless, though I'm not totally tied to Ubuntu it is kinda convenient.

6

The easiest way to solve this is to add a derived key from the first partition to to the second disk by running:

/lib/cryptsetup/scripts/decrypt_derived sda1_crypt > new_key_file
cryptsetup luksAddKey /dev/sdb1 new_key_file  # prompts for an existing key
shred -u new_key_file                        # remove the key file

Then replace the sdb1_crypt line in /etc/crypttab with:

sdb1_crypt /dev/sdb1 sda1_crypt \
    luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

With this, the second disk can be automatically mounted as soon as the first disk is available.

Of course, you need to replace sda1 and sdb1 with the correct partitions/labels you use and do not forget to run update-initramfs -u after the change and to add a corresponding entry to /etc/fstab.

  • Many thanks for the pointer to decrypt_derived, I hadn't come across it before. I'll do a bit more reading and see how I get on. – Tim Abell Jan 20 '14 at 14:32
  • Found these related questions: unix.stackexchange.com/questions/32541/… and askubuntu.com/questions/43432/… and this informative cryptsetup faq code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions – Tim Abell Jan 20 '14 at 14:32
  • I have a question I haven't been able to figure out / google the answer to yet. If I do the above will I still be able to use the existing passphrase to decrypt sdb1, or will I have to use key from sda from then on? I ask because I don't mind losing sda so much as it's just the system disk and is encrypted to protect cached data and the swap partition, I care more about sdb as that's where the user data will be. So if sda fails, does that make sdb permanently irrecoverable? (Assuming I don't backup sda's luks header) – Tim Abell Jan 20 '14 at 14:40
  • 1
    @TimAbell With luks, you can have up to 8 keys per device. The luksAddKey command adds another key to the existing one. It does not replace it - so it the command should be safe. It prompts for an existing key, not the new one. – jofel Jan 20 '14 at 14:57
  • 1
    @TimAbell The luksAddKey command was wrong in the answer (did simply not work without any damage). I fixed it now. On journal filesystems, the shred command may not work properly. To be on the safe side, put the temporary file with the new key on a tmpfs. – jofel Jan 20 '14 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.