[mkj]

For Ubuntu or Debian the dropbear-initramfs package should handle most of it, it looks like https://hamy.io/post/0005/remote-unlocking-of-luks-encrypted... is an alright run through.

Another approach is to use something like OpenWRT as a bootloader then pivot_root into the real distribution after unlocking it - not sure there are any good instructions online for that though. I'm using it on a Raspberry Pi colocated 14000km away for https://dropbear.nl, it works pretty well. Kexec is great for remote kernel upgrades too.

[loxias]

You are rocking my world. :D

When I first started switching my VPSs to having full disk encryption, I think it was around lenny though it might have been squeeze. Anyway, me and another peer thought it would be good practice to, while we figured we'd never cover every possible surface, find a standard deployment for debian VMs where even though we have no physical access to the hosts, wherever possible minimized the ability of an employee at a hosting company accessing our precious, precious bits.

The memory hadn't come back when I wrote my first comment, but one of the ideas we had at the time was shoving sshd inside the initrd! But we concluded it would be hard -- involving not only making a static build of sshd (which I did some eons ago when I had foolish opinions concerning /bin /usr/bin) but also probably trimming code away from it or adding executable compression, and modifying the initrd creation scripts....either way -- too much complexity.

So I went the route previously described. Now I learn that not only is there an ssh implementation which i can statically link into a tiny binary (which helps some other projects...), but someone went threw the trouble of making a modified initrd package with it!

Fantastic. Look for an email from me soon offering help on a specific project I noticed on your github...

I'm well aware of building my own scripts that use chroot/pivot_root tricks -- I personally like using them for making small boxes that run everything from ram and keep no persistent state.

But just out of random curiosity, what's the advantage of using OpenWRT?

[mkj]

> But just out of random curiosity, what's the advantage of using OpenWRT?

I can't remember the exact reason, maybe it was because then the "bootloader" is completely decoupled from the main OS which makes upgrading kernels etc easier. It was about 5 years ago I set it up.

I should add, all the Debian initramfs work has been contributed by various people over the years - full credit to people such as the Debian maintainers, currently Guilhem Moulin.

[loxias]

> should add, all the Debian initramfs work has been contributed by various people over the years

Oh certainly, I would have assumed it was.

All I know for sure is that many moons ago I would have loved this feature, could have probably done it myself at great great great effort but didn't want to, and now, hey, here it is :) progress!!

As for decoupling and lowering complexity... <tiny voice> occasionally i miss LILO... </>

I've been paging through the code (dropbear) so far, very clear. Glad that there's TCP forwarding, as it opens the door to another possible solution in search of a problem. Namely, with USB over IP tunneled through dropbear, a user would have the ability to plug in a yubikey or some sort of challenge response device. ; )

Also, I sent you a note.

[theandrewbailey]

I've set my Ubuntu server up with dropbear-initramfs almost 2 years ago, but a few months ago, it stopped working. Since 18.04 was imminent, I decided to wait and not fix it, and hope my new UPS keeps it running.