Currently, all my remote servers of any import use LUKS to encrypt the PVs. My /boot is a tiny unencrypted filesystem containing just the kernel, and an initrd, which prompts for my decryption key before booting. (afaict, the standard setup)
For remote servers, I reboot them and then have to use a serial console to type in the LUKS password.
Are you saying that with this, I could put an ssh server in the initrd (and I guess I'd have to make sure network was up as well), that I could log in to to provide my LUKS password???? Because that would be ... beautiful.
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.
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?
> 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.
> 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. ; )
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.
Basicaly when linux boot from initrd it starts "/init" executable and chroots to your system (ok, it is using pivot_root and it is slightly more complex), but idea it is same as manually mounting filesystems and doing chroot then starting executable /bin/init
For remote servers, I reboot them and then have to use a serial console to type in the LUKS password.
Are you saying that with this, I could put an ssh server in the initrd (and I guess I'd have to make sure network was up as well), that I could log in to to provide my LUKS password???? Because that would be ... beautiful.