| ▲ | pfexec 4 days ago |
| Friendly reminder that you've been able to automatically unlock fully-encrypted Linux systems via TPM for years since it was added to systemd... (Here's a nickel kid...) |
|
| ▲ | xrisk 4 days ago | parent | next [-] |
| This is not the same thing is it? Arch Wiki mentions something about having to install a separate ssh server into initramfs to support ssh’ing into fully encrypted systems. systemd-cryptenroll seems to be about storing encryption keys into the TPM so that they can be decrypted automatically at boot (?) Apologies if I misunderstood something. |
| |
| ▲ | epistasis 4 days ago | parent | next [-] | | I'm looking for what you're describing, some way to remote unlock a system. Is this the wiki page you're talking about? https://wiki.archlinux.org/title/Dm-crypt/Specialties#Remote... However, I'd prefer that the box is not on the general internet, but only over my tailscale net. I wonder if tailscale will also fit in the initramfs... | | |
| ▲ | xrisk 4 days ago | parent [-] | | Yeah I was looking at that page. Found this btw: https://github.com/darkrain42/tailscale-initramfs | | |
| ▲ | epistasis 4 days ago | parent [-] | | Thanks! I'm just getting back into Linux boot issues for the first time in multiple decades, and boy is it different than I remember. It's pretty incredible to be able to dump all this stuff directly into the boot system. Now to see what Omarchy has done to give the fancy LUKS password entry... |
|
| |
| ▲ | conradev 4 days ago | parent | prev [-] | | and I imagine that the initramfs is not encrypted and trivially modifiable? Apple is able to achieve this securely because their devices are not fully encrypted. They can authenticate/sign the unencrypted system partition. | | |
|
|
| ▲ | kwk1 4 days ago | parent | prev | next [-] |
| More similar to the usage pattern in the original post is "dropbear-initramfs", e.g. https://wiki.debian.org/DropBear |
|
| ▲ | Dylan16807 3 days ago | parent | prev | next [-] |
| If you want it to automatically unlock via TPM then you turn filevault off. This is protection on top of that. |
|
| ▲ | adestefan 4 days ago | parent | prev | next [-] |
| But that uses TPM backed keys only protected by the TPM PSRs. Someone could still swipe your box and unlock the disk. |
|
| ▲ | rnhmjoj 4 days ago | parent | prev | next [-] |
| Also possible without a TPM: you just put openssh into the initrd, so you can log in and type the password to unlock the root. (It's technically not full-disk encryption because the kernel and initrd are in plaintext, but everything else is) |
| |
| ▲ | pfexec 4 days ago | parent [-] | | What do you authenticate against? Your shadow file is in the unencrypted area leaving it susceptible to offline attack. With the TPM you can fully disable password auth over SSH. | | |
| ▲ | auguzanellato 4 days ago | parent | next [-] | | My Raspberry Pi some time ago had a setup where only public key auth was enabled for LUKS unlock, so I only had to have an authorized_keys file unencrypted. | |
| ▲ | rnhmjoj 4 days ago | parent | prev [-] | | Correct, someone with physical access could run a MitM attack and steal your passphrase. I just find this extremely unlikely, so I honestly don't care. |
|
|
|
| ▲ | leakycap 4 days ago | parent | prev | next [-] |
| If this worked as well/seamlessly across updates and hardware revisions as your friendly reminder makes it seem, today's Mac news wouldn't be all over the place getting praise. |
|
| ▲ | trueismywork 4 days ago | parent | prev [-] |
| Link? |
| |
