Are there any advantages from putting Linux on encrypted root at bare metal server
There are always advantages of having FDE, including when a theft occurs. While ofc FDE will not protect against theft, at least the data on the drive(s) will be secure.
If you're "hosting" other people's data, I think this there's even more good reason to use encryption, whether that data is sensitive or not.
Personally, I use FDE for everything. It's only one step further than an encrypted data partition, so I don't see why not. Here's an sample single-disk (no RAID) layout:
/dev/sda
├─ /dev/sda1 : EFI System Partition
├─ /dev/sda2 : /boot partition, not encrypted
└─ /dev/sda3 : LUKS crypt container
└─ hello_lvm - LVM Physical Volume and "hello_lvm" Volume Group
├─ hello_lvm/root : LVM volume, OS / partition
└─ hello_lvm/home : LVM volume, /home partition
LVM-over-LUKS gives you the flexibility to still "partition" your drive
as you wish while having everything encrypted and you can have a single
key open everything. Though, of course, you might want to put the OS
root on its own separate partition and encrypt that with a separate LUKS
container with its own protection, meaning you will need to unlock both
at boot.
I hear GRUB these days supports LUKS so maybe an encrypted /boot is possible too, but I've never tried it myself. I might be wrong.
if I often access remotely server from ssh, and sometimes need to reboot it?
These advantages would not be negated from the need to access or reboot the machine.
I want to protect against burglary and I'm not sure whether doing full disk encryption is a right way to go. Maybe should I just instead of trying to focus on the software side try to take more care of physical security?
It's a tough one, but I think these are complementary measures. Unless you can guarantee 100% impenetrable physical security, then there's always the potential of burglary, regardless how small, and you might want to ensure the data is not accessible.
What about key supplied during unlocking server after reboot or manually power on? Giving remotely password doesn't seems safe to me.
There are ways around this. Like Grant had suggested earlier, an OOB console is one way, and so is a lightweight ramdisk SSH server.
The latter ramdisk approach can be very user friendly as it's a simple "ssh + provide unlock password" experience. It's relatively easy to set up, and can be set up in a secure manner.
You can set up the ramdisk SSH server to only allow a specific set of authorised SSH keys for login, through the usual "authorized_keys" and prevent password access. This is good practice for regular SSH too.
I have only done this on Debian and Fedora, but I don't see why it can't be done on Gentoo. For Debian I've used "dropbear-initramfs" and on Fedora I've used "dracut-sshd" [1] which is just a Dracut module and should work on most Dracut-generated ramdisks. The GitHub page shows that a contributor has tested it on Gentoo and it works. gentoo-kernel-bin uses Dracut, so that could be something to try.
You can also strengthen your remote access measures by not exposing any ports that do not need to be, and this includes SSH. If your router supports it, configuring OpenVPN or Wireguard is a very neat approach to securely access your home network. If not, a cheap SBC such as a Raspberry Pi (even an older model should suffice) could be used to run OpenVPN or Wireguard and provide access. Wireguard is very easy to set up compared to OpenVPN, I would highly recommend it for something like this.
So to recap, not-exposing SSH ports, using self-hosted VPN to access your home network, and only using authorised SSH keys for access should be pretty good.
Hope this helps. I'm sure there's other ways too. [1] https://github.com/gsauthof/dracut-sshd
signature.asc
Description: OpenPGP digital signature
