HOWTO: Unlock a LUKS encrypted root partition via ssh

[hyper_ch]

(1) create a random keyfile

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4

(2) chmod keyfile to root-read only

sudo chmod 0400 /root/keyfile

(3) add the key as new possible authorization

sudo cryptsetup luksAddKey /dev/sdX /root/keyfile

You should first be prompted to authorize yourself with an existing keyfile or password and the should get an output like that:

Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.

(4) Open /etc/crypttab

sudo nano /etc/crypttab

and add the new harddisk there (you may already have it added, if so then just alter the existing one)

sdX_crypt      /dev/sdX  /root/keyfile  luks

(5) Open /etc/fstab

sudo nano /etc/fstab

and add the new harddisk there (you may already have it added, if so then just alter the existing one)

/dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2

That would mount it at /media/sdX

That's it, the second harddisk will get unlocked automatically upon booting normally.

[EuleLL]

It works!!! I can't tell you how thankful I am!

You should get a golden medal...


now i can finally put the server away from the desk and completly restart it remotley.

Thanks again,

EuleLL

[hyper_ch]

good

[pixelbrei]

Wow, exactly what i need, nice tutorial! Could not test it so far though, because i need to encrypt root on the target machine first...

There still are a few things that i have to say

1) about your coldboot / encryption password attacks:
i spend some time thinking about "security" when it comes to remote machines,
and i do not believe you can protect this password by other means than physically
securing your machine against access from unauthorized persons.
Think about an attacker stealing the dropbear host keys, emulating your machine,
and capturing the password... You can try to get some "security by obscurity", but that's it, i believe.

2) about those many-disk encryption with all the same password:
i used to build my own initrd-init-script which asks for a password, and echoes it
to the cryptsetup commands... sadly it was unportable like hell, so i'll rather use
the "key file on encrypted root" variant. if an attacker gets into the system far
enough to read this file, he could also use other variants of getting the key, like
changing initrd, reading the RAM content, etc. so having the key in a file is no
further security impact i think.

3) i have a difficult situation here, which i'll try to solve, but hints from your side
are welcome, too
i have a multi-boot machine, with a root-encrypted winxp (truecrypt) on it. the
truecrypt bootloader is required to come up _before_ grub gets control. so i need some
way to make the truecrypt bootloader pass on to grub after some timeout, or such.
i did not yet investigate this problem, but i'll post if i find a solution.

so, thanks for this thread!
greets
pixelbrei

[hyper_ch]

1) about your coldboot / encryption password attacks:
i spend some time thinking about "security" when it comes to remote machines, and i do not believe you can protect this password by other means than physically securing your machine against access from unauthorized persons. Think about an attacker stealing the dropbear host keys, emulating your machine, and capturing the password... You can try to get some "security by obscurity", but that's it, i believe.

Well, you could put that initrd onto a cd-rom and make that bootable... then you could first check if it's a cd-rom, you could even generate then a md5 check of that cd... in that case, in order to capture, someone would have to boot alternatively and then have a differen md5 checksum... but even that could be fooled somehow... there is no true security but I think it's protected enough and by standard method a cd-rom boot with dropbear should be sufficient to calm everyone but the most paranoid ones (they wouldn't probably go online anyway).

2) about those many-disk encryption with all the same password:
i used to build my own initrd-init-script which asks for a password, and echoes it to the cryptsetup commands... sadly it was unportable like hell, so i'll rather use the "key file on encrypted root" variant. if an attacker gets into the system far enough to read this file, he could also use other variants of getting the key, like changing initrd, reading the RAM content, etc. so having the key in a file is no
further security impact i think.

same here... if one can access somehow to root partition and alter it then you are not safe anway... so you only need to care about how secure the root partition...

3) i have a difficult situation here, which i'll try to solve, but hints from your side are welcome, too
i have a multi-boot machine, with a root-encrypted winxp (truecrypt) on it. the truecrypt bootloader is required to come up _before_ grub gets control. so i need some way to make the truecrypt bootloader pass on to grub after some timeout, or such. i did not yet investigate this problem, but i'll post if i find a solution.

if I understand correctly, then truecypt will put its own bootloader and then goes directly to boot the ms bootloader... I'm not sure if you can change that... however it should be possible to alter the windows bootloader in a way, that it can load linux instead...
A quick google serach returned this: http://www.linuxquestions.org/questi...ual-boot-8294/
I did not read it completely but it seems to be a howto on how to boot linux from a windows boot loader. Let me know of the results.

[pixelbrei]

if I understand correctly, then truecypt will put its own bootloader and then goes directly to boot the ms bootloader... I'm not sure if you can change that... however it should be possible to alter the windows bootloader in a way, that it can load linux instead...
A quick google serach returned this: http://www.linuxquestions.org/questi...ual-boot-8294/
I did not read it completely but it seems to be a howto on how to boot linux from a windows boot loader. Let me know of the results.

wow, that was a quick response
i didn't look into your link, because i searched the truecrypt forum and
found a way of inverting the order of grub and truecrypt.
just tested it, and it worked fine. here is the link:
http://forums.truecrypt.org/viewtopic.php?p=41943#41943
so, i will now set up my machine to encrypted root fs

[hyper_ch]

nice, will have a look at the TC forum also

[pixelbrei]

Ok, now i tried this script, and there are two things that should be mentioned:

1) it is (or may be) necessary to add your nic driver module to /etc/initramfs-tools/modules. i had to do so.
2) the script does not work with splash screen enabled (at least not for me).

but apart from that, it works like a charme really cool!

[say2sky]

(1) create a random keyfile

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4

(2) chmod keyfile to root-read only

sudo chmod 0400 /root/keyfile

(3) add the key as new possible authorization

sudo cryptsetup luksAddKey /dev/sdX /root/keyfile

You should first be prompted to authorize yourself with an existing keyfile or password and the should get an output like that:


(4) Open /etc/crypttab

sudo nano /etc/crypttab

and add the new harddisk there (you may already have it added, if so then just alter the existing one)

sdX_crypt      /dev/sdX  /root/keyfile  luks

(5) Open /etc/fstab

sudo nano /etc/fstab

and add the new harddisk there (you may already have it added, if so then just alter the existing one)

/dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2

That would mount it at /media/sdX

That's it, the second harddisk will get unlocked automatically upon booting normally.

following command

cryptsetup luksOpen /dev/sdb1 sdb1 --key-file /etc/keys/keyfile

can be used when needed to map the encrypted partition

my question is
is it possible to map encrypted root partition of remote system which have dropbear running from user's desktop by using a keyfile stored in user's desktop system?

use something similar

ssh username@192.168.0.100 cryptsetup luksOpen /dev/sdb1 sdb1 --key-file remote system's keyfile

[hyper_ch]

in one of my old howtos (rsyncing) I have a command to issue a command over ssh. Have a look here: http://www.howtoforge.com/rsync_incr...apshot_backups

Search especially for the command above this line: This will run a the mysql backup scrip on the production server.

With that you can execute a shell script (or run a command) on the other server. However I'm not sure how you would send to local stored key over the ssh command to the "exec" part on the remote server. You'll have to try that yourself.