Thanks for your replies… 
Quote:
Originally Posted by lifewoutmilk
What's the point of disk encryption, if all the keys for decryption are stored on the disk unencrypted? Sounds like a waste of time.
|
Well, that's a part of my question, and why I don't feel that keydisk is an option. With a passfile, if it has to go on an uncrypted partition… I would be able to store it elsewhere - put it in place before reboot, and delete when I'm done. That was at least the idea if there aren't any other good options to manage the server remotely.
Quote:
Originally Posted by jggimi
Quote:
|
...1 with the system (2 partitions: 1 small + 1 w all partitions)...
|
I don't understand what this intends. |
I meant 2 disks, both with a small partition and one big. The small partition on disk#2 for /altroot and on disk#1 - incase I need it for the passfile, or I can put other stuff on it. The large partition on disk#1 with the system, and on disk#2 just one big one to mount on the system (for backups/syncs).
Quote:
Originally Posted by jggimi
When the softraid device is to be used, bioctl(8) or the bootloader will require a passphrase - entered by the operator at the console or terminal, or obtained from a "passfile" stored on a disk.
Optionally a "keydisk" may be used.
|
Yes, it's just that there will be no operator on the other side if I put it @neighbour. So finding a solution that I can reboot over ssh and get it to unlock is what I'd need, if possible.
Quote:
Originally Posted by jggimi
My understanding is that the best practice for both passfile and keydisk is to use external drives, such as USB sticks, should either be operationally necessary.
|
I've seen an example using the passfile stored in /root to be able to automatically unlock the other disk. So if the first disk is encrypted as well, that one is safe. It's just the first one. Perhaps using an unencrypted disk/partition, and the like above - get the file before reboot and delete afterwards?
But then, that thing about what systems/platforms that can('t) unlock. If
macppc can't do it - a semi-encrypted system would be able to reboot normally? and I can unlock the rest manually from my ssh connection?
And there are no other remote solutions? Like GNU/Linux are using dropbear, tinyssh etc.
(Here's a Debian example.)
Best thing would be if there were like a “cryptreboot”, who asked for the password
before reboot instead of when booting.
