[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature
debian at x.ray.net
debian at x.ray.net
Sat Feb 16 01:37:04 UTC 2008
> This sounds like an interesting approach. As I got from #465901, this
> will enable dropbear per default if cryptroot is detected. While I like
> the idea to be able to enable ssh support for initramfs, I object
> against this default behaviour. Not everyone with cryptroot is in need
> of remote access during boot process. Thus I suggest to disable the
> whole feature per default, and make it configurable in any case.
ok. not my preference, but i understand the rationale.
this behaviour is implemented in the dropbear patch. i guess the
dropbear maintainer will read the related initramfs-tools and this
report, and i will submit a patch with the always-no-default if he
> Also, please resend the patch in unified format (diff -rNu).
>> in the initramfs scripts, the target might be unlocked (from remote) in
>> the background. so on non-successful cryptsetup exit, check whether the
>> target is unlocked, only otherwise act on it as a failure.
>> for this unlocking in the background (and if successful, killing the
>> waiting cryptsetup), the cryptcreate script is added.
>> to call this unlocking script from remote, dropbear has to be added to
>> the initramfs, so dropbear is added to the suggested list.
> I have to admit that I don't get that. In your patch, a script
> /sbin/cryptcreate is created, which itself uses the variables
> $cryptcreate and $crypttarget. This script is made executable, but I
> cannot find the place where it actually is executed. Also, how does the
> script know about the variables used by it?
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1807 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080216/ea41f4a2/attachment.bin
More information about the Pkg-cryptsetup-devel