[pkg-cryptsetup-devel] Scripting hooks for entering a password

[Shawn Rose]

On Thu, Jun 22, 2017 at 9:19 PM, Guilhem Moulin <guilhem at debian.org> wrote:

> Basically, the premout script forks dropbear sshd in the background as
> soon as possible; by using command="/bin/cryptroot-unlock" as
> authorized_keys(5) option, users can either enter the password at the
> initramfs shell or through ssh.
>
> I couldn't avoid either searching for askpass through the process list,
> though :-/
>

Alright. One reason I was asking is because in #debian-kernel they
repeatedly said "Don't fork, don't subshell, it's bad". I guess it's good
to know it's not just me who had to do it.


> The disk name and source are respectively found in the askpass process'
> CRYPTTAB_NAME and CRYPTTAB_SOURCE environment variables.
>

Huh, don't know why I missed that. Sure is cleaner than what I was doing at
any rate.


> > is that if clevis fails to get the password and the user enters a
> > password manually, then after a while the script will close out the
> > subshell saying that sleep can't be found.
>
> Do you have busybox installed?  It provides sleep, we'll soon split the
> cryptsetup package so the initramfs integration can require busybox.
>

It is: In fact, clevis requires bash to be imported. The reason it might
error out with sleep can not be found was that I don't really have a way to
tell when the password is unlocked, and at first I didn't exit out after an
attempt was made. So, if it wasn't successful and you entered the password
as usual, the forked shell would keep trying to loop until initramfs was
unmounted. I since changed that though: At first, I was thinking if
cryptroot had to decrypt more than one disk. Of course, it doesn't support
that anyways, so I just made it so if it detects askpass it exits out.

Thanks for the tips.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20170622/e9a4c4f2/attachment.html>