Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #92629 > unrolled thread

Bug#1108404: please fix in trixie -- also breaks dracut-sshd remote-unlock

Started byThomas Deutschmann <whissi@whissi.de>
First post2026-05-20 16:20 +0200
Last post2026-05-20 16:20 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#1108404: please fix in trixie -- also breaks dracut-sshd remote-unlock Thomas Deutschmann <whissi@whissi.de> - 2026-05-20 16:20 +0200

#92629 — Bug#1108404: please fix in trixie -- also breaks dracut-sshd remote-unlock

FromThomas Deutschmann <whissi@whissi.de>
Date2026-05-20 16:20 +0200
SubjectBug#1108404: please fix in trixie -- also breaks dracut-sshd remote-unlock
Message-ID<MWPW9-6zoi-1@gated-at.bofh.it>
Package: dracut-core
Version: 106-6

Hi,

This bug is still present in Debian trixie (current stable, 13.5
as of 2026-05-20), which still ships dracut 106. The upstream fix
(renaming the systemd-sysusers module so it runs last, plus a
follow-up removing the (g)shadow file it created) landed in
dracut-ng and is part of the 107 release.

Could this be addressed for trixie users in one of two ways:

   1) backport the upstream patches onto 106 as a stable update
      via the next trixie point release, or
   2) make a newer dracut available to trixie users via
      trixie-backports (forky currently has 110-12).

Motivation: this is not only an issue in the emergency shell
scenario the bug was originally filed for. It also breaks an
important practical use case -- early-userspace remote access
via dracut-sshd (and similar setups) used to unlock
LUKS-encrypted root filesystems over SSH on headless machines.
With dracut 106 as shipped in trixie, the systemd-sysusers
module bakes `root:!unprovisioned:...` into the initramfs
`/etc/shadow`, which sshd then treats as a locked account and
rejects public key authentication. The net effect is that a
Debian stable user who follows the standard dracut-sshd setup
cannot unlock their encrypted root remotely -- they have to
physically attend the machine, which defeats the point of the
setup.

For reference, this has now also been documented on the
dracut-sshd side:

https://github.com/gsauthof/dracut-sshd/issues/92#issuecomment-3583525213

Thanks for considering.


-- 
Regards,
Thomas

[toc] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web