Your message dated Tue, 19 Mar 2024 13:50:34 +0100
with message-id <[email protected]>
and subject line Re: Bug#1067154: dropbear-initramfs: please allow generating
distinct hostkey instead of copying host's
has caused the Debian Bug report #1067154,
regarding dropbear-initramfs: please allow generating distinct hostkey instead
of copying host's
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1067154: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067154
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dropbear-initramfs
Version: 2022.83-1+deb12u1
Severity: normal
X-Debbugs-Cc: [email protected]
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
--- End Message ---
--- Begin Message ---
Hi Guilhem,
On Tue, Mar 19, 2024 at 01:04:27PM +0100, Guilhem Moulin wrote:
> 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.
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.
>
> 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?
AFAIU the *hook* script runs at initrd generation time. I wasn't suggesting
to use transient keys :)
Thanks,
--Daniel
signature.asc
Description: PGP signature
--- End Message ---
