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

[Jonas Meurer]

On 16/02/2008 David Härdeman wrote:
> On Sat, Feb 16, 2008 at 02:37:04AM +0100, debian at x.ray.net wrote:
>> the idea is that when the boot process is waiting at the passphrase  
>> prompt, it is possible to log in via ssh and manually call a script  
>> which prompts for the passphrase, and in case the passphrase is correct 
>> and the root-fs is unlocked, kills the process waiting at the console,  
>> so the boot process continues.
>> i admit that the name 'cryptcreate' for this script is quite  
>> unintuitive, so i changed that in the attached new, unified diff: the  
>> script's name is now 'unlock' - i hope this is more intuitive.
>> the variables will be expanded when the script is written, and as  
>> $cryptcreate is already used to store the cryptsetup call, this seemed  
>> to me to be the most straightforward way to guarantee that the  
>> cryptsetup call to unlock the cryptroot from the shell is identical to  
>> the cryptsetup call at the console (and likewise the two crypttarget  
>> tests should always test the identical target).
>
> 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...

The only way I can imagine to implement that in a keyscript would be to
loop forever in the keyscript until the target device exists. But that
again would need work in cryptdisks and/or initramfs script, as in this
case cryptsetup doesn't need to be invoked anymore afterwards.
Currently output of the keyscript is delivered as key to cryptsetup,
that would not work in that case. Did I miss something?

greetings,
 jonas