
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Jurvis </span></font><span style="background-color: rgba(255, 255, 255, 0);">LaSalle wrote:</span>wouldn't unattended boot require the system to decrypt the hdd itself and thus hold the keys itself? the req seems antithetical to FDE unless i'm missing something...<br><div>I made my own home-brew key-server to provided unattended boot capability for servers as follows:</div><div><br></div><div>- Set up a small Linux server on the LAN with a USB thumb drive. (It's a cheap raspberry pi but can be any old machine not used for anything else.)</div><div><br></div><div>- Use cryptsetuo to create a LUKS volume on the thumb drive, create a keyserver role account, and put your various servers' disk-volume passphrases into subdirectories on the drive.</div><div><br></div><div>- On your servers, set up an fstab entry to mount the thumb drive after network startup, and add the_netdev keyword to the fstab entries for each of your local volumes that you want encrypted. The easiest method I found to mount the thumb drive is volume type "sshfs", if I set up the keyserver role user's ssh keypair in the root's ssh config.</div><div><br></div><div>By this method, you can activate key service on that central key server for however long you want; as soon as you dismount the thumb drive, your encryption keys are secure. And you can have a separate pass phrase for every volume. Don't forget to make spare copies of that all-important thumb drive!</div><div><br></div><div>This works for my tiny home setup but I could see it working just as well for a 500-instance AWS cloud setup, assuming you set up the VPCs with vpn tunnel back to that thumb-drive server (your MacBook, say, if you configure a reserved private IP address for it).</div><div><br></div><div>-rich </div><div><br></div></body></html>