Your message dated Fri, 5 Dec 2025 22:36:26 +0100 with message-id <[email protected]> and subject line Re: Bug#1121980: dropbear-initramfs: Can't put password through stdin to unlock LUKS partition since Debian 13 has caused the Debian Bug report #1121980, regarding dropbear-initramfs: Can't put password through stdin when a pty has been allocated 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.) -- 1121980: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121980 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dropbear-initramfs Version: 2025.88-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Since Debian 13, i'm no longer able to unlock the LUKS cryptroot through SSH. In Debian 12, I was able to do something like : echo "password" | ssh root@remote_server and it worked to unlock the LUKS partition. However, now it's no longer possible and the LUKS partition stays locked. I do not know if it is related to a change with dropbear or another package in Debian 13. * What exactly did you do (or not do) that was effective (or ineffective)? echo "password" | ssh root@remote_server * What was the outcome of this action? LUKS partition is not unlocked. * What outcome did you expect instead? LUKS is unlocked. *** End of the template - remove these template lines *** -- System Information: Debian Release: 13.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.87.2-microsoft-standard-WSL2 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dropbear-initramfs depends on: pn busybox | busybox-static <none> pn dropbear-bin <none> pn initramfs-tools <none> ii udev 257.8-1~deb13u2 Versions of packages dropbear-initramfs recommends: pn cryptsetup-initramfs <none> dropbear-initramfs suggests no packages.
--- End Message ---
--- Begin Message ---On Fri, 05 Dec 2025 at 22:16:27 +0100, Matthieu Meurillon wrote: > Yes it works with both commands ! Awesome, closing this then :-) > So I mean, this should be enough to close the case, but I'm really curious > why the behavior changed between the two Debian versions. I don’t even know > which package is causing the issue. All I know is that my method worked on > Debian 12 but no longer works on Debian 13. The linefeed-handling behavior has been unchanged since many release, I'm quite certain that echo "$PASSPHRASE" | ssh -T root@remote_server didn't work either with bookworm and earlier (it tries "$PASSPHRASE\n" as passphrase just like the here-string). There might be some PTY handling magic that have changed (in the SSH client, in dropbear, or in ansible's command module) between Bookworm and Trixie, but I don't see that as a bug since one shouldn't allocate a PTY when redirecting the standard input. -- Guilhem.
signature.asc
Description: PGP signature
--- End Message ---
