[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature

[David Härdeman]

On Mon, February 18, 2008 12:24, debian at x.ray.net wrote:
> david wrote:
>> the patch idea looks cool, but I'm wondering if it would perhaps be
>> better implemented as a keyscript? See README.initramfs for some
>> documentation on how the keyscripts work...ideally that would mean that
>> no changes would be necessary to the main cryptsetup initramfs
>> scripts...
>
> i beleive it's not a bad idea that the goal should be to implement a
> method to be able to enter the passphrase via ssh, too - with emphasis
> on the 'too', i.e. without disabling the prompt on the console. looking
> at the current script, the cryptkeyscript part does not look like it's
> better suited for this to me...
> a different approach would be to get access to the console via ssh. but
> thinking about a console running in a screen or something like that
> convinced me that the 'do it in the background, then kill the dangling
> console process' is - at least for now - the better approach.

If you want both, it could still be done as a keyscript. Let the keyscript
do the prompt and wait for user input, meanwhile the script could also
create a fifo and wait for input of a passphrase via that fifo in
parallel.

It might be harder to implement as a shell script...but it should be
doable...something like "echo some_prompt > /dev/stdout; mkfifo
/tmp/cryptpass; cat /dev/stdin /tmp/cryptpass | read REPLY" (haven't
tested it so I can't be sure it works).

Then cryptunlock could just read a passphrase and pipe it to /tmp/cryptpass.

The advantage is that there is no need to kill cryptsetup processes and no
need to change cryptsetup initramfs scripts. The keyscript could also
write the name of the device it is currently waiting for a passphrase for
to some file which the cryptunlock util could read so that it can provide
a more user friendly prompt.

-- 
David Härdeman