Hello,

I'm going to run on my server a few services for me and friends like
static HTML pages, gitea, jabber server, and mailing lists.

Are there any advantages from putting Linux on encrypted root at bare metal server if I often access remotely server from ssh, and sometimes need to reboot it? What about key supplied during unlocking server after reboot or manually power on? Giving
remotely password doesn't seems safe to me.

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?

Thank you all gen2 folks,
whiteman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/16/2025 12:59 PM, whiteman808 wrote:

Hello,

Are there any advantages from putting Linux on encrypted root at bare metal server if I often access remotely server from ssh, and sometimes need to reboot it? What about key supplied during unlocking server after reboot or manually power on? Giving

remotely password doesn't seems safe to me.

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?

Burglary is a difficult use case to protect against, because as you
point out you need to provide the key somehow at boot.  There are
TPM-based approaches that are not well-supported on Linux distros which
try to ensure that the key is only readable if the disk is booted
normally, but you're still vulnerable to any physical access OS
vulnerability.

I run servers with full disk encryption on SOME of my storage, but not
the OS drives. I store the key in a file on the OS drive. This obviously provides no security against burglary, but the benefit is that when a
disk with sensitive data fails it is encrypted with a strong key (no
memorable passphrase). You need both the OS disk and the encrypted disk
to read anything sensitive, so I can just toss the failed disk in the
trash. This also allows unattended boot.

Another approach you could consider is putting the key on another host available over the network. Your initramfs/etc could use a credential
stored on it to access the remote host and retrieve the disk key. The
remote host could be a Pi hidden someplace non-obvious. Then if the host
is stolen and not kept powered on continuously (ie not a sophisticated attacker) the disk won't be readable, but it would boot just fine as
long as it is attached to your LAN.

There might be some other variations on a theme like that using some
sort of credential vault software. Approaches like that could also be
used to remotely disable the device if you can't access it - the
credential vault could be told to not provide the key any longer.

In any case there are definitely use-cases for full disk encryption that
still add value even if it isn't as secure as having to remember a LUKS
key on boot.

--

Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/16/25 11:59 AM, whiteman808 wrote:

Hello,

Hi,

Are there any advantages from putting Linux on encrypted root at bare
metal server ...

I think so.

But I've not yet done it myself. I've only used LUKS for a data file
system.

... if I often access remotely server from ssh, and sometimes need
to reboot it?

I don't think the method or frequency of access alters the advantages of
FDE.

What about key supplied during unlocking server after reboot or
manually power on? Giving remotely password doesn't seems safe to me.

I think this is where an OoB console access to provide the key, or
initial RAM disk based SSH server can come into play.

I've actually had FDE provide /faster/ access to data than unencrypted
for weird reasons related to caching.

There's also, destroy the key and the drive is cryptographically
sanitized and available for re-use without concern.

I added a key to the FDE on my work notebook a couple of jobs ago and
had that key stored in a 4 MB partition (smallest I could make) on a
flash drive. (Raw partition, not file.) So when I booted my computer
in the dock, the key could be found and automatically unlock the FDE.
If I booted not connected to the dock, I had to enter my FDE password.

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?

Are you worried about disk theft or system theft?

The former is easier to protect against than the latter.

Take a look at a solution that Red Hat supports. I'm sure Gentoo can be
made to support it:

Clevis (client) and the Tang server

It's meant to be a way for servers to unlock FDE. I don't remember the particulars at the moment.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/05/2025 03:06, Grant Taylor wrote:

Are you worried about disk theft or system theft?

The former is easier to protect against than the latter.

I believe modern hardware will automatically encrypt the disk and store
the key in the TPM. At BIOS level. So that disk is only readable on that computer.

(There are ways to back up the key, but to a first approximation, take
the disk out of the computer and it's cryptographically wiped.)

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) DQo+IEFyZSB0aGVyZSBhbnkgYWR2YW50YWdlcyBmcm9tIHB1dHRpbmcgTGludXggb24gZW5jcnlw dGVkIHJvb3QgYXQgYmFyZSBtZXRhbCBzZXJ2ZXINCg0KVGhlcmUgYXJlIGFsd2F5cyBhZHZhbnRh Z2VzIG9mIGhhdmluZyBGREUsIGluY2x1ZGluZyB3aGVuIGEgdGhlZnQgDQpvY2N1cnMuIFdoaWxl IG9mYyBGREUgd2lsbCBub3QgcHJvdGVjdCBhZ2FpbnN0IHRoZWZ0LCBhdCBsZWFzdCB0aGUgZGF0 YSANCm9uIHRoZSBkcml2ZShzKSB3aWxsIGJlIHNlY3VyZS4NCg0KSWYgeW91J3JlICJob3N0aW5n IiBvdGhlciBwZW9wbGUncyBkYXRhLCBJIHRoaW5rIHRoaXMgdGhlcmUncyBldmVuIG1vcmUgDQpn b29kIHJlYXNvbiB0byB1c2UgZW5jcnlwdGlvbiwgd2hldGhlciB0aGF0IGRhdGEgaXMgc2Vuc2l0 aXZlIG9yIG5vdC4NCg0KUGVyc29uYWxseSwgSSB1c2UgRkRFIGZvciBldmVyeXRoaW5nLiBJdCdz IG9ubHkgb25lIHN0ZXAgZnVydGhlciB0aGFuIGFuIA0KZW5jcnlwdGVkIGRhdGEgcGFydGl0aW9u LCBzbyBJIGRvbid0IHNlZSB3aHkgbm90LiBIZXJlJ3MgYW4gc2FtcGxlIA0Kc2luZ2xlLWRpc2sg KG5vIFJBSUQpIGxheW91dDoNCg0KL2Rldi9zZGENCuKUnOKUgCAvZGV2L3NkYTEgOiBFRkkgU3lz dGVtIFBhcnRpdGlvbg0K4pSc4pSAIC9kZXYvc2RhMiA6IC9ib290IHBhcnRpdGlvbiwgbm90IGVu Y3J5cHRlZA0K4pSU4pSAIC9kZXYvc2RhMyA6IExVS1MgY3J5cHQgY29udGFpbmVyDQogICAg4pSU 4pSAIGhlbGxvX2x2bSAtIExWTSBQaHlzaWNhbCBWb2x1bWUgYW5kICJoZWxsb19sdm0iIFZvbHVt ZSBHcm91cA0KICAgICAgIOKUnOKUgCBoZWxsb19sdm0vcm9vdCA6IExWTSB2b2x1bWUsIE9TIC8g cGFydGl0aW9uDQogICAgICAg4pSU4pSAIGhlbGxvX2x2bS9ob21lIDogTFZNIHZvbHVtZSwgL2hv bWUgcGFydGl0aW9uDQoNCkxWTS1vdmVyLUxVS1MgZ2l2ZXMgeW91IHRoZSBmbGV4aWJpbGl0eSB0 byBzdGlsbCAicGFydGl0aW9uIiB5b3VyIGRyaXZlIA0KYXMgeW91IHdpc2ggd2hpbGUgaGF2aW5n IGV2ZXJ5dGhpbmcgZW5jcnlwdGVkIGFuZCB5b3UgY2FuIGhhdmUgYSBzaW5nbGUgDQprZXkgb3Bl biBldmVyeXRoaW5nLiBUaG91Z2gsIG9mIGNvdXJzZSwgeW91IG1pZ2h0IHdhbnQgdG8gcHV0IHRo ZSBPUyANCnJvb3Qgb24gaXRzIG93biBzZXBhcmF0ZSBwYXJ0aXRpb24gYW5kIGVuY3J5cHQgdGhh dCB3aXRoIGEgc2VwYXJhdGUgTFVLUyANCmNvbnRhaW5lciB3aXRoIGl0cyBvd24gcHJvdGVjdGlv biwgbWVhbmluZyB5b3Ugd2lsbCBuZWVkIHRvIHVubG9jayBib3RoIA0KYXQgYm9vdC4NCg0KSSBo ZWFyIEdSVUIgdGhlc2UgZGF5cyBzdXBwb3J0cyBMVUtTIHNvIG1heWJlIGFuIGVuY3J5cHRlZCAv Ym9vdCBpcyANCnBvc3NpYmxlIHRvbywgYnV0IEkndmUgbmV2ZXIgdHJpZWQgaXQgbXlzZWxmLiBJ IG1pZ2h0IGJlIHdyb25nLg0KDQo+IGlmIEkgb2Z0ZW4gYWNjZXNzIHJlbW90ZWx5IHNlcnZlciBm cm9tIHNzaCwgYW5kIHNvbWV0aW1lcyBuZWVkIHRvIHJlYm9vdCBpdD8NCg0KVGhlc2UgYWR2YW50 YWdlcyB3b3VsZCBub3QgYmUgbmVnYXRlZCBmcm9tIHRoZSBuZWVkIHRvIGFjY2VzcyBvciByZWJv b3QgDQp0aGUgbWFjaGluZS4NCg0KPiBJIHdhbnQgdG8gcHJvdGVjdCBhZ2FpbnN0IGJ1cmdsYXJ5 IGFuZCBJJ20gbm90IHN1cmUgd2hldGhlciBkb2luZyBmdWxsIGRpc2sgZW5jcnlwdGlvbiBpcyBh IHJpZ2h0IHdheSB0byBnby4gTWF5YmUgc2hvdWxkIEkganVzdCBpbnN0ZWFkIG9mIHRyeWluZyB0 byBmb2N1cyBvbiB0aGUgc29mdHdhcmUgc2lkZSB0cnkgdG8gdGFrZSBtb3JlIGNhcmUgb2YgcGh5 c2ljYWwgc2VjdXJpdHk/DQoNCkl0J3MgYSB0b3VnaCBvbmUsIGJ1dCBJIHRoaW5rIHRoZXNlIGFy ZSBjb21wbGVtZW50YXJ5IG1lYXN1cmVzLiBVbmxlc3MgDQp5b3UgY2FuIGd1YXJhbnRlZSAxMDAl IGltcGVuZXRyYWJsZSBwaHlzaWNhbCBzZWN1cml0eSwgdGhlbiB0aGVyZSdzIA0KYWx3YXlzIHRo ZSBwb3RlbnRpYWwgb2YgYnVyZ2xhcnksIHJlZ2FyZGxlc3MgaG93IHNtYWxsLCBhbmQgeW91IG1p Z2h0IA0Kd2FudCB0byBlbnN1cmUgdGhlIGRhdGEgaXMgbm90IGFjY2Vzc2libGUuDQoNCj4gIFdo YXQgYWJvdXQga2V5IHN1cHBsaWVkIGR1cmluZyB1bmxvY2tpbmcgc2VydmVyIGFmdGVyIHJlYm9v dCBvciBtYW51YWxseSBwb3dlciBvbj8gR2l2aW5nIHJlbW90ZWx5IHBhc3N3b3JkIGRvZXNuJ3Qg c2VlbXMgc2FmZSB0byBtZS4NCg0KVGhlcmUgYXJlIHdheXMgYXJvdW5kIHRoaXMuIExpa2UgR3Jh bnQgaGFkIHN1Z2dlc3RlZCBlYXJsaWVyLCBhbiBPT0IgDQpjb25zb2xlIGlzIG9uZSB3YXksIGFu ZCBzbyBpcyBhIGxpZ2h0d2VpZ2h0IHJhbWRpc2sgU1NIIHNlcnZlci4NCg0KVGhlIGxhdHRlciBy YW1kaXNrIGFwcHJvYWNoIGNhbiBiZSB2ZXJ5IHVzZXIgZnJpZW5kbHkgYXMgaXQncyBhIHNpbXBs ZSANCiJzc2ggKyBwcm92aWRlIHVubG9jayBwYXNzd29yZCIgZXhwZXJpZW5jZS4gSXQncyByZWxh dGl2ZWx5IGVhc3kgdG8gc2V0IA0KdXAsIGFuZCBjYW4gYmUgc2V0IHVwIGluIGEgc2VjdXJlIG1h bm5lci4NCg0KWW91IGNhbiBzZXQgdXAgdGhlIHJhbWRpc2sgU1NIIHNlcnZlciB0byBvbmx5IGFs bG93IGEgc3BlY2lmaWMgc2V0IG9mIA0KYXV0aG9yaXNlZCBTU0gga2V5cyBmb3IgbG9naW4sIHRo cm91Z2ggdGhlIHVzdWFsICJhdXRob3JpemVkX2tleXMiIGFuZCANCnByZXZlbnQgcGFzc3dvcmQg YWNjZXNzLiBUaGlzIGlzIGdvb2QgcHJhY3RpY2UgZm9yIHJlZ3VsYXIgU1NIIHRvby4NCg0KSSBo YXZlIG9ubHkgZG9uZSB0aGlzIG9uIERlYmlhbiBhbmQgRmVkb3JhLCBidXQgSSBkb24ndCBzZWUg d2h5IGl0IGNhbid0IA0KYmUgZG9uZSBvbiBHZW50b28uIEZvciBEZWJpYW4gSSd2ZSB1c2VkICJk cm9wYmVhci1pbml0cmFtZnMiIGFuZCBvbiANCkZlZG9yYSBJJ3ZlIHVzZWQgImRyYWN1dC1zc2hk IiBbMV0gd2hpY2ggaXMganVzdCBhIERyYWN1dCBtb2R1bGUgYW5kIA0Kc2hvdWxkIHdvcmsgb24g bW9zdCBEcmFjdXQtZ2VuZXJhdGVkIHJhbWRpc2tzLiBUaGUgR2l0SHViIHBhZ2Ugc2hvd3MgDQp0 aGF0IGEgY29udHJpYnV0b3IgaGFzIHRlc3RlZCBpdCBvbiBHZW50b28gYW5kIGl0IHdvcmtzLiAN CmdlbnRvby1rZXJuZWwtYmluIHVzZXMgRHJhY3V0LCBzbyB0aGF0IGNvdWxkIGJlIHNvbWV0aGlu ZyB0byB0cnkuDQoNCllvdSBjYW4gYWxzbyBzdHJlbmd0aGVuIHlvdXIgcmVtb3RlIGFjY2VzcyBt ZWFzdXJlcyBieSBub3QgZXhwb3NpbmcgYW55IA0KcG9ydHMgdGhhdCBkbyBub3QgbmVlZCB0byBi ZSwgYW5kIHRoaXMgaW5jbHVkZXMgU1NILiBJZiB5b3VyIHJvdXRlciANCnN1cHBvcnRzIGl0LCBj b25maWd1cmluZyBPcGVuVlBOIG9yIFdpcmVndWFyZCBpcyBhIHZlcnkgbmVhdCBhcHByb2FjaCB0 byANCnNlY3VyZWx5IGFjY2VzcyB5b3VyIGhvbWUgbmV0d29yay4gSWYgbm90LCBhIGNoZWFwIFNC QyBzdWNoIGFzIGEgDQpSYXNwYmVycnkgUGkgKGV2ZW4gYW4gb2xkZXIgbW9kZWwgc2hvdWxkIHN1 ZmZpY2UpIGNvdWxkIGJlIHVzZWQgdG8gcnVuIA0KT3BlblZQTiBvciBXaXJlZ3VhcmQgYW5kIHBy b3ZpZGUgYWNjZXNzLiBXaXJlZ3VhcmQgaXMgdmVyeSBlYXN5IHRvIHNldCANCnVwIGNvbXBhcmVk IHRvIE9wZW5WUE4sIEkgd291bGQgaGlnaGx5IHJlY29tbWVuZCBpdCBmb3Igc29tZXRoaW5nIGxp a2UgdGhpcy4NCg0KU28gdG8gcmVjYXAsIG5vdC1leHBvc2luZyBTU0ggcG9ydHMsIHVzaW5nIHNl bGYtaG9zdGVkIFZQTiB0byBhY2Nlc3MgDQp5b3VyIGhvbWUgbmV0d29yaywgYW5kIG9ubHkgdXNp bmcgYXV0aG9yaXNlZCBTU0gga2V5cyBmb3IgYWNjZXNzIHNob3VsZCANCmJlIHByZXR0eSBnb29k Lg0KDQpIb3BlIHRoaXMgaGVscHMuIEknbSBzdXJlIHRoZXJlJ3Mgb3RoZXIgd2F5cyB0b28uDQoN ClsxXSBodHRwczovL2dpdGh1Yi5jb20vZ3NhdXRob2YvZHJhY3V0LXNzaGQNCg==
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsGpBAEBCABdBYJoKGPBCZDHHRBH4xmOczUUAAAAAAAcABBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnpxsCWYcszU7kDgWYXgXdDxYhBChWW5VCWm3b IxkkL8cdEEfjGY5zAABtsA//WktaKd0Jr36Tw4MGEDIKHHDVV+y7xyTlhKZF fHNifyJ1pOsxzfPPPtiCU+r8td598QeCLV80vVjBOk4MI1gv3h28TMe2b8J9 ac1cRdNHReMKK6LY+8y59jpH2gEWxCUHpe3/qnrKYgtBb7NaPokNjmnmt7tm 0aTFJatXf5MJduy9zfDc/ZtBKWb3DgYQVZnexq6kLkGNJXcqr6Ue6fkm6vxO QNZ15yXa5q24pSz4ypYig30/NVpO22CfPuB/OSRTaNwDXTK0fz9haCsbWSDc zRGdB5rx8KVycB9G8uL+k/Cvkk0gLb6UTF1UF6mM72vpNT4eHKCVSRafwW71 TA81Dkp021X2uD/7PVdgZbAa7OwkWhZNw2oB/sW91Ib8+g/0ObeCVZ4Dhq+x rhuL7ZOu675bMHRS24u8ta05s/frtfjAdzFgqqB5S2k00vbDyldOPHpuP82m hnBoK/cWuDcqL3EJPFUTt9TRhLAUpsK0eluimAtSIUGov2I+zCQUmmABn0V1 0QDFI86IdiPdIxtZtqWQFHgrkVept8r2FJCg6sErSU3LnE17an6lCpuxdwBG 8+BeJMw26ra4tDSgBODZMYOGCIgvmKsczaWDUKdXzaY3pH4/RqkjJLfJVrT+ EfFmUpPTM4t1OXt5MgnTKIrZ/mizJPeQNX683+UOf9jjo/E=
=LAIj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/17/25 3:04 AM, Wol wrote:

I believe modern hardware will automatically encrypt the disk and store
the key in the TPM. At BIOS level. So that disk is only readable on that computer.

Some systems have that capability. But all of the systems that I've
looked at don't enable it automatically.

Sadly, it doesn't offer any protection if the entire system is taken,
Hence the question of what to protect.

This also offers no protection against physical based / connected attacks.

(There are ways to back up the key, but to a first approximation, take
the disk out of the computer and it's cryptographically wiped.)

I get what you're saying, but if you put it back in the same system the
data is available again. Thus the data wasn't wiped. Conversely
destroy the key and now you can't get the data back without massive
brute force.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/17/2025 8:43 AM, Rahul Sandhu wrote:

Hi,

You may want to look into TPM2-based disk encryption; during normal
operation it's basically transparent. My servers all have an encrypted
root partition, and I do not need to enter a password to boot it as the decryption keys are stored in the TPM. Take a look at this page[1] for information on how to do it with Clevis, however I would recommend the
usage of systemd-cryptenroll(1) instead for systemd systems[2].

I didn't realize that this had progressed so far. With LUKS you could presumably also set a passphrase in case the PCRs get messed up.

This is basically how most corporate laptops are configured.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)