1

I run a small computer with an encrypted data partition. So that I have as little effort as possible to decrypt the hard disk after a reboot (no extra ssh login, password input etc.), I thought about storing the KeyFile on a small Raspberry Zero in the local network in an encrypted container. The Raspberry runs 247 and mounts the encrypted container to /mnt/KeyStore/. As soon as the computer boots, it fetches the KeyFile from the Raspberry, decrypts and mounts the data partition, and then destroys the KeyFile. The decryption process is so dependent on the Raspberry.

I have added a working sample code.

# Load SSH Agent and add Keys
eval `ssh-agent -s -t 5m`
ssh-add -t 5m /root/.ssh/*.prv

# Create RamFS
[[ -d /root/myramfs ]] || mkdir /root/myramfs
mount ramfs /root/myramfs/ -t ramfs

# Get the KeyFile from the KeyStore
scp root@192.168.1.13:/mnt/keyStore/keyFile /root/myramfs/keyFile

# Decrypt the device
cryptsetup open /dev/sda1 storage --key-file /root/myramfs/keyFile

# Remove the KeyFile and close the RamFS memory
shred --remove --zero /root/myramfs/keyFile
umount /root/myramfs

# Mount the device
mount /dev/mapper/storage /mnt/storage -o noatime,defaults

Are there any improvements or concerns?

closed as too broad by forest, AndrolGenhald, Tom K., Xander, Teun Vink Nov 7 '18 at 7:10

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What if the ssh host key change? It could be either an attack (spoofing) or a misconfiguration. You should force which behavior you want by appropriate flags (fail makes you immune to attacks but then the system does not boot, pass allows you to boot without detecting attacks). While not security related I would use another filename, based on the host connecting, and I would certainly not use root as username for that operation. – Patrick Mevzek Nov 1 '18 at 22:38
  • See this other answer where it is also discussed how to do it in reverse (sshd running on the booting host, and a remote machine connecting to it to put the key instead of your host getting it from elsewhere): serverfault.com/a/884715/396475 – Patrick Mevzek Nov 1 '18 at 22:49
  • 2
    This question is too broad without defining your threat model. Without that, there's no way to tell what concerns would be relevant or what improvements would be beneficial. – forest Nov 2 '18 at 1:42