I want to setup a Slackware64 13.37 server with RAID1, LVM2, and LUKS with automount. I already know how to setup RAID1/LUKS/LVM on the server, what I would like to be able to have is the LUKS partition (which will contain the LVM volumes) automount in case I have to restart the server remotely.

I'm guessing I will have to a key file that for the automount but I'm not sure how to do it.

I'm trying to achieve what Ubuntu does during setup where it allows you to choose to encrypt the home folder and automount it so it's fully accessible remotely (via SSH for example) after a reboot but only for the entire filesystem (not including /boot which will have to stay unencrypted).

I would also like to make sure (if possible) that if I do use a key file to automount the LUKS partition the file itself won't just reside on the server accessible to anyone with psychical access and a LiveCD.

Thanks.

As I understand your question, I don't think this is going to be possible.

In order for LUKS to unlock a partition it needs either a passphrase, or a keyfile. These need to be able to be input at boot. If you need to unlock the root partition before you can continue the boot, there is no way to enter a passphrase remotely (since services such as ssh aren't started yet) and unless the keyfile is accessible to the server (on a disk or flash key) it won't be able to unlock that way either. This is why Ubuntu only does the /home directory. (BTW encrypting partitions only to automount them using system stored keys is a waste of time.)

There are two other possibilities.

The first is to use server hardware that has an onboard remote hardware console accessible through the network.

The second is to place the keyfile on a remote system capable of responding to the LUKS request for the keyfile. For proper security this network connection and the system on which the keyfile resides should be secure. Note: I have not tried this with LUKS so I am not certain if it is even a viable option.

I guess my Google-fu isn't what it used to be, I found several posts about remotely unlocking LUKS partitions.

http://www.debian-administration.org/articles/579
http://www.howtoforge.com/unlock-a-l...-ssh-on-ubuntu
https://wiki.archlinux.org/index.php...r.29_partition

I'll have to try it out and see what happens.

Thank for responding.

I have been pondering the same question for a good while - as I wanted to secure the data on my server with encryption in case it gets stolen - but, also, to be able to cope with the server restarting automatically. I abviously can't be in front of it to type a passphrase when it restarts. Nor is there any point in leaving something like a usb memory stick plugged in all the time, with the keys on it in case it reboots.

What I ended up doing is the following:

1. Store all confidential/personal data under /srv. For example, Dovecot stores all my imap emails in /srv/dovecot, Samba keeps all the shares under /srv/samba and so on.
2. Keep all this stuff on another partition (/dev/sda3 in my case) which is encrypted (so it is actually /dev/mapper/lukssda3 after LUKS unlocks it).
3. Mount /dev/mapper/lukssda3 under /srv.
4. Change services/software/daemons which store data under /srv to manual start, so they don't start automatically during boot - when there would be no /srv available and mounted.

During boot, the server restarts fine - it just doesn't mount /srv or start things like imap, samba and my Asterisk server. However, everything else starts just fine, including openvpn. All I have to do is login remotely, unlock the encrypted partition with a passphrase, mount it and start the necessary services.

It is not a fully automatic solution, but as the server is on a UPS and power cuts are very rare around here - having to login remotely to start services after a reboot would be a rare event.

On the other hand - if somebody happens to steal the server - they would just get access to the run-off-the-mill part of the system - which doesn't contain any sensitive data. I can jut re-create my OpenVPN CA and new certificates - so even that is not a problem.

If you want to be extra cautious - you can even tell LUKS to encrypt the swap.

At least that's what I came up with. I would actually be glad if somebody could point out any weaknesses in this particular arrangement. It is obviously not designed to protect against somebody trying to gain access from the Internet, or somebody sitting in front of the server and taking their time (although if they reboot it, the partition would be locked). Those are different matters, to be dealt with other tools.

Hope the above helps.