Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure

["Stefan G. Weichinger" <lists@xunil.at>]

Am 18.05.2010 22:06, schrieb Jan Engelhardt:
> 
> On Tuesday 2010-05-18 21:33, Stefan G. Weichinger wrote:
>> Am 18.05.2010 20:57, schrieb Stefan G. Weichinger:
>> 
>>> On the other hand I would like to get that done right, sure.
>>> 
>>> Any howto without pmt-ehd that would keep me safe from newlines
>>> etc (btw. there were NO newlines in that hexdump-output)?
>> 
>> Created a new encrypted LV and used "--key-file=-" as mentioned
>> in:
>> 
>> http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt
>>
>>
>> 
Still no success with 2.x ...
> 
> Debugging preexisting containers is hard (because people usually
> don't share that.)
> 
> Since you are starting with a blank one, I would love to see your 
> failing testcase -- i.e. sequence of shell commands to trigger the 
> unanticipated behavior, such as the existing testcases in 
> src/t-crypt:
> 
> echo that | openssl whatever cryptsetup luksFoo,Format,Open that. 
> mkfs cryptsetup luksClose mount.crypt -o [...]
> 
> It does not need to follow t-crypt's style, just the sequence alone 
> is good.


I saved my history, unfortunately only the last steps were kept, but I
am able to reconstruct:

The block-device is /dev/VG01/sgwcrypt ...

#I tried a more complicated KEY
KEY=`head -c 79 /dev/urandom`

# avoid newline here
echo -n $KEY | openssl aes-256-cbc > /etc/security/super.key

# format it, using "--keyfile=-" as mentioned in bugs ...
openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
--key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat
/dev/VG01/sgwcrypt

# open it
openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
--key-file=-  luksOpen /dev/VG01/sgwcrypt newhome

# create fs on the open luks-volume
mkfs.ext3 /dev/mapper/newhome

# mount the new fs
mount /dev/mapper/newhome /mnt/gschwind

all this worked OK so far, but not with pam_mount.

OK?

Stefan