u/bed_potato_2935

Setting up FDE, UKI an TPM 2 auto decryption on my Debian 13 machine

Hello Reddit,

I've been tinkering with Debian 13 as a server for my home. However, I kept running into issues where I would follow a guide to get my Debian 13 server into the desired state, only to be rewarded with various forms of broken.

Desired State:

UEFI Secure boot with a UKI and LUK full Disk encryption, minus /boot and ESP, back by TPM for auto drive unlocking.

Base system:

- Debian 13 net install ISO

- LVM + Encrpted Disk via luks and password

- One main partitions for / and separate for swap and /boot.

- Only standard and openssh were installed as part of tasksel

I followed various guides nut they seemed a bit incomplete to me.

It turns out that Debian 13's default initramfs uses the older \`initramfs-tools\`, rather than some of the newer alternatives, and \`systemd-cryptenroll\` doesn't work properly with it out of the box.

I also learned that `mokutil’ works with the shim/MOK key database, not the actual TPM hardware. Meanwhile, I was sitting there resetting TPM keys a few times, wondering why nothing happened.

So, I switched to Clevis for TPM-based unlocking, and now everything works. I hope it all correct. But I think that is a separate reddit question.

That brings me to my main questions:

1. Should I switch from ‘initramfs-tools’ to ‘dracut’?
   Dracut does offer some systemd benefits such as journald getting logs from the intitramfs stage.
2. Should I switch from GRUB to ‘systemd-boot’ and embrace the full systemd boot environment?

2.1. If so, can someone recommend a good guide or documentation for doing this properly? I've followed a few guides, but I always felt like I ended up in some sort of half-migrated state.

2.2. If I transition the boot infrastructure to ‘systemd-boot’ should I completely uninstall GRUB afterward?

I'm already making use of some of the systemd-related packages/tools, including ‘systemd-boot-efi’ and \`systemd-ukify\`.

3. Is there an official Debian Wiki/documentation page that describes the recommended process for accomplishing the above?

If so, please point me in the right direction. ([https://wiki.debian.org/SecureBoot\](https://wiki.debian.org/SecureBoot) < is more of a faq)

Thank you in advance for your time and responses!

Hello Reddit, 

Question: is there real value for vpn in large companies (WFH) when modern zero trust exists?

Brief tldr: 

I think VPNs for remote work are often outdated in modern zero-trust, cloud-first environments.

I think SSO, TLS, firewalls, and gateways already cover much of the access control VPNs are used for.

I think VPNs add extra overhead,complexity, and latency.

I think this argument does not work for homelabs or small single location businesses 

Longer argument 

I apologize if this is an obvious question or answered before,  I looked around and saw parts of possible answers but not full ones.

I don’t understand the need to use a VPN when working from home, in the erra of zero trust architecture and cloud services making up a bulk of the infrastructure that we use.

I have worked for bigger and smaller tech companies, and many require a vpn when working from home.  I question the need for the vpn in most modern last few decades architectures.
 In the land of zero trust,  many things go through an SSO solution before you get access to the underlying service. So there are gatekeepers all over the place.  In fact, the same VPNs make use of the same sso providers as the application.  Thus, if there was an authentication weakness, wouldn’t the VPN and the application both be equally affected.  I would understand more if the VPN requires something like a machine certificate to get access.

If access was tied to remote security hardware/software attestation.  I would understand the value of VPNs, even more.  But so many companies I’ve seen have loose then expected end point controls.  Many even allow admin access for the users own laptop/endpoint. Attestation is incredibly hard and restrictive.

A large part of the infrastructure is hosted other places/cloud anyway.  Many companies use gsuite, zoom or Microsoft cloud solutions with sharepoint and teams.  So most vpn are split tunnels so a large portion of corporate digital items are not even vpn bound.

Most modern services are web bases. A good portion of office workers, interface with backend servers most of the time and a very little local processing is done.  The application is mostly just a front end that communicates over https based technologies. Most other technologies use an encrypted variant such as secure ldap.  Of course, this is not universal for example CAD and other related services run locally sometimes, but do they not make use of cloud file transfers solutions?  If a software has an insecure transport layer,  would a proxy tunnel  be easier?

Remote management protocols require authentication.  I am not as versed in rdp but many ssh system face internet all the time.  Does putting a vpn in front really add much.  RDP is usually warned against making Internet facing, because of the password authentication default.  But, many SSH solution I’ve worked with also use a password solution.  Is adding a VPN in front of the management protocols really adding much when the VPN is also password and 2FA based.  See point 1.  And if we’re saying, the VPN can be used to filter access to the lower layer or protocols, could you not accomplish the same effect with Geo base restrictions at the firewall level?

The legacy system argument,  where the direct system cannot be modified and the transport/auth is insecure or non-existent. I would argue a gateway solution that talks the modern protocol and tls would proxy the connection just as good.  Additionally even if the vpn is in place,  I have still seen companies put in the security gate way internally.

Everything is on a private ip/network argument. I find this to be a weaker argument, as the vpn effectively extends your network (though controlled) into public. Additionally vpn are at a raw network level. SSO gateways only extent select apps and services. Again both use similar auth (point 1).  Yes firewalls will restrict existing traffic, but those would be in place in either solution.

One major downside of a vpn is packet in packet situation and double encryption work.  Encryption is not as profitably expensive as it once was back in the day, but it still adds a network toll to your communications, doing it twice seems to be unfruitful. Additionally, VPNs must wrap every single packet in a header or effectively a mini packet of its own. This reduces the total amount of space each packet can dedicate to the raw data.

Finally,  is a vpn is over tcp,  this could add its own overhead and latency.  Though most recommend to use udp for a VPN.

For homelab or single location business this entire argument is not applicable.  

Edit: Thank you all for the replies, it really give me much to think about I am trying to read as many of the responses as possible.