Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
On Tue, 19 Mar 2024 at 13:50:34 +0100, Daniel Gröber wrote: > Ah, that makes sense. Well that's easy enough for me to fix then not sure > how I missed that while staring at the hook script. I really should have my > green tea before reporting bugs ;) > > Sorry for the noise. No worries :-) I believe removing /etc/dropbear/initramfs/dropbear_*_host_key and running `dpkg-reconfigure dropbear-initramfs` will generate new keys for initramfs use. -- Guilhem. signature.asc Description: PGP signature
Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
Control: tag -1 moreinfo Hi, On Tue, 19 Mar 2024 at 12:37:08 +0100, Daniel Gröber wrote: > In that setup there's really no point to reusing the hosts' private > keys and expose them in the initrd unencrypted. Agreed, but AFAICT that's not the case anymore since 2015.68-1. New host keys are generated at postinst stage, and used for initramfs only. But not when upgrading of course, as this would break pinned key material. https://salsa.debian.org/debian/dropbear/-/commit/1c4975743d659b121231b30f8e641b211b1448ee So AFAICT the host's private keys are only used when upgrading from pre-2015.68-1, and in that case the change should be announced via d/NEWS. > Would you accept a patch to allow configuring the dropbear hook > behaviour to generate a new host key instead of reusing the host's > key? What would be use case of generating transient keys when generating the initramfs image? Such keys would not be pinable, and if that's acceptable then a similar behavior (keys generated at boot time not at initramfs generation time) can be achieved with DROPBEAR_OPTIONS="-R". Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
Package: dropbear-initramfs Version: 2022.83-1+deb12u1 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Guilhem, I would like to use a fresh hostkey for dropbear running during init. You see I find it quite jarring for me to unexpectedly land in an earlyboot environment without warning when ssh'ing in (because there was a power outage, say). To fix this I configure init to use an IP address distinct from the system proper. In that setup there's really no point to reusing the hosts' private keys and expose them in the initrd unencrypted. Would you accept a patch to allow configuring the dropbear hook behaviour to generate a new host key instead of reusing the host's key? Thanks, --Daniel
