On 2017-07-04 10:34:04, Guilhem Moulin wrote: > On Mon, 03 Jul 2017 at 19:08:52 -0400, Antoine Beaupré wrote: >> On 2017-07-03 23:21:25, Guilhem Moulin wrote: >>> Actually I came up with a better solution that doesn't rely on the >>> behavior of dropbear. It passes my tests, but perhaps you could try it >>> as well? Then we won't have to go through this again after the Buster >>> release ;-) >> >> Hehe.. That's a great idea! Any chance this could hit stretch as well? >> Or would that be... stretching it? *rimshot* > > Aha :-) If there is enough interest I guess we could maintain a > backport as well.
That may make more sense yes. >>> When its standard input is a TTY, the script should now wait until all >>> configured devices are unlocked, and prompt for passphrases when >>> required. Since it exits on its own once it has detected that there is >>> nothing more to to, SSH sessions should be terminated cleanly (ie, no >>> hang), at least when there no shell involved. (Well hang might still >>> occur as polling is racy, but it's merely convenience at stake and it >>> seems to work fine here with boot and resume.) >>> >>> When its standard input is not a TTY the behavior is unchanged: the >>> whole standard input is dumped to the askpass FIFO, regardless of NUL >>> bytes or newlines (the TTY prompt above doesn't work with binary >>> passphrases), then the script exits. Hence one needs to invoke it as >>> many times as there are devices to unlock. >> >> from my perspective, I ssh into the box and call the script. it asks me >> for the passwords one after the other without any noticable delay, than >> the scripts exits and shortly after the ssh session is killed. > > Great, thanks for the feedback! The new workflow will be documented in > Sec. 8 “Remotely unlock encrypted rootfs” of README.Debian. > > > https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/diff/debian/README.Debian?id=d80853c26f67a31c769e6fc1859803d9a602ca96 Excellent. >> thanks, i guess this is done? or do we need to document the "initramfs" >> tag in crypttab better? > > Anything in particular you have in mind? crypttab(5) currently reads: > > initramfs > The initramfs hook processes the root device, any resume devices > and any devices with the “initramfs” option set. These devices > are processed within the initramfs stage of boot. As an > example, that allows the use of remote unlocking using dropbear. I did see that, but only after you mentioned it. I guess the problem is the documentation is kind of split up all over the place. There's that README.Debian, then there's: * /usr/share/doc/cryptsetup/README.initramfs.gz * "Some keyscripts have an own README file at /usr/share/doc/cryptsetup/" * crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8) * /usr/share/doc/cryptsetup/FAQ.gz * /usr/share/doc/dropbear-initramfs/README.initramfs Which one is relevant here? Probably the last one? Who knows! :) In this case, I should have read README.initramfs and crypttab(5) but even the latter is not clearly outlined in Sec. 8 of the README.Debian... > […] > keyscript > The executable at the indicated path is executed with the key > file from the third field of the crypttab as its only argument > and the output is used as the key. This also works with > encrypted root filesystems via initramfs if the executable is > self-contained (i.e. an executable which does not rely on any > external program which is not present in the initramfs > environment). > […] > WARNING: With systemd as init system, this option might be > ignored. At the time this is written (December 2016), the > systemd cryptsetup helper doesn't support the keyscript option > to /etc/crypttab. For the time being, the only option to use > keyscripts along with systemd is to force processing of the > corresponding crypto devices in the initramfs. See the > 'initramfs' option for further information. Not sure how or if this applies to my current use case. :) > See you at DebConf in a month, I guess ;-) Definitely :) A. -- Le féminisme n'a jamais tué personne Le machisme tue tous les jours. - Benoîte Groulx
