[gentoo-user] Kernel upgrade and now LUKS failure.

[gentoo-user] Kernel upgrade and now LUKS failure.

[Jason Dusek]

  I have an encrypted block device, `/dev/sda2', which is
  mounted as my root filesystem. I recently installed this
  system -- I've been away from Gentoo for awhile -- and used
  gentoo sources 2.6.31-r6. When the kernel upgrade rolled
  around, to 2.6.32-r7, I installed and rebooted and then my
  passphrase didn't work anymore. The error message:

    Command failed: No key available with this passphrase.

  However, rebooting with my old kernel works fine so I'm not
  sure what the problem is. Could it be a different version of
  `cryptsetup'? When the device can't be opened on boot, I have
  the option to drop to a shell. I try to run `cryptsetup' and I
  get the same error -- so maybe that's my problem? Would
  different versions of `cryptsetup' be incompatible with
  devices encrypted by older versions? That seems brittle and
  dangerous to me.

--
Jason Dusek

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

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Am 03.05.2010 18:56, schrieb Jason Dusek:
>   I have an encrypted block device, `/dev/sda2', which is
>   mounted as my root filesystem. I recently installed this
>   system -- I've been away from Gentoo for awhile -- and used
>   gentoo sources 2.6.31-r6. When the kernel upgrade rolled
>   around, to 2.6.32-r7, I installed and rebooted and then my
>   passphrase didn't work anymore. The error message:
> 
>     Command failed: No key available with this passphrase.
> 
>   However, rebooting with my old kernel works fine so I'm not
>   sure what the problem is. Could it be a different version of
>   `cryptsetup'? When the device can't be opened on boot, I have
>   the option to drop to a shell. I try to run `cryptsetup' and I
>   get the same error -- so maybe that's my problem? Would
>   different versions of `cryptsetup' be incompatible with
>   devices encrypted by older versions? That seems brittle and
>   dangerous to me.
> 
> --
> Jason Dusek
> 

Some rough guesses to get you started:

1. Keyboard layout specific passphrase? Do you use a non-american
keyboard layout? Maybe it has not been loaded at the time you enter the
passphrase.

2. Check that all necessary components (hash algorithm, block cipher,
encryption algorithm) are compiled into the new kernel.

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Stefan G. Weichinger]

Am 03.05.2010 18:56, schrieb Jason Dusek:
>   I have an encrypted block device, `/dev/sda2', which is
>   mounted as my root filesystem. I recently installed this
>   system -- I've been away from Gentoo for awhile -- and used
>   gentoo sources 2.6.31-r6. When the kernel upgrade rolled
>   around, to 2.6.32-r7, I installed and rebooted and then my
>   passphrase didn't work anymore. The error message:
> 
>     Command failed: No key available with this passphrase.

I see something similar here.

Upgraded from tuxonice-sources-2.33-r1 to -r2 on my thinkpad.

I use an encrypted /home mounted by pam_mount, it reads the key from a
file so there is no keyboard involved.

When I login I don't get /home mounted.

/var/log/messages says:

pam_mount(mount.c): crypt_activate_by_passphrase: Operation not permitted

but with both kernels, -r1 and -r2

I now fiddle around with downgrading cryptsetup etc.

Any hints welcome, thanks.

Stefan

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

[walt]

On 05/04/2010 03:06 AM, Stefan G. Weichinger wrote:

> I use an encrypted /home mounted by pam_mount, it reads the key from a
> file so there is no keyboard involved.
>
> When I login I don't get /home mounted.
>
> /var/log/messages says:
>
> pam_mount(mount.c): crypt_activate_by_passphrase: Operation not permitted

I don't have a pam_mount, where does it come from?  Perhaps it needs a
reference to pam_ssh.so?

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

[Stefan G. Weichinger]

Am 04.05.2010 18:54, schrieb walt:

>> pam_mount(mount.c): crypt_activate_by_passphrase: Operation not
>> permitted
> 
> I don't have a pam_mount, where does it come from?  Perhaps it needs
> a reference to pam_ssh.so?

What do you mean with "where does it come from?" ?

It's in portage ... for example

http://home.coming.dk/index.php/2009/05/20/encrypted_home_partition_using_luks_pam_

shows how to make use of it.

I am not sure which HOWTO I followed ... but it is the same approach.
What would the reference to pam_ssh.so look like?


Googling for "crypt_activate_by_passphrase" I found:

http://code.google.com/p/cryptsetup/issues/detail?id=58

which says:

"crypt_activate_by_passphrase is the new API"

Could it be the case that my current setup somehow uses "the new API"
which isn't available yet in some package?

I don't yet have the whole picture ...

Thanks, Stefan

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

[Stefan G. Weichinger]

Am 04.05.2010 19:38, schrieb Stefan G. Weichinger:

> I don't yet have the whole picture ...

I did some "emerge -avuDN world", quite some packages updated even
though I am doing "emerge -avu world" nearly every day ...

After a reboot and setting debug to 1 for pam_mount it says:

May  4 21:25:38 enzo slim: pam_mount(pam_mount.c:364): pam_mount 2.0:
entering auth stage
May  4 21:25:38 enzo slim: gkr-pam: invalid option: use_first_pass
May  4 21:25:38 enzo slim: pam_unix(slim:session): session opened for
user sgw by (uid=0)
May  4 21:25:38 enzo slim: pam_mount(pam_mount.c:552): pam_mount 2.0:
entering session stage
May  4 21:25:38 enzo slim: pam_mount(misc.c:38): Session open: (uid=0,
euid=0, gid=0, egid=0)
May  4 21:25:38 enzo slim: pam_mount(mount.c:196): Mount info:
globalconf, user=sgw <volume fstype="crypt" server="(null)"
path="/dev/mapper/VG01-crypthome" mountpoint="/home/sgw"
cipher="aes-cbc-plain" fskeypath="/etc/security/verysekrit.key"
fskeycipher="aes-256-cbc" fskeyhash="md5"
options="data=journal,commit=15" /> fstab=0
May  4 21:25:38 enzo slim: command: 'mount.crypt'
'-ocipher=aes-cbc-plain' '-ofsk_cipher=aes-256-cbc' '-ofsk_hash=md5'
'-okeyfile=/etc/security/verysekrit.key' '-odata=journal,commit=15'
'/dev/mapper/VG01-crypthome' '/home/sgw'
May  4 21:25:38 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May  4 21:25:38 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May  4 21:25:40 enzo slim: pam_mount(mount.c:64): Errors from underlying
mount program:
May  4 21:25:40 enzo slim: pam_mount(mount.c:68):
crypt_activate_by_passphrase: Operation not permitted
May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:520): mount of
/dev/mapper/VG01-crypthome failed
May  4 21:25:40 enzo slim: command: 'pmvarrun' '-u' 'sgw' '-o' '1'
May  4 21:25:40 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May  4 21:25:40 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:440): pmvarrun says
login count is 1
May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:642): done opening
session (ret=0)
May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:115): Clean global
config (0)
May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:132): clean system
authtok=0x80e6870 (0)
May  4 21:25:40 enzo seahorse-daemon[1426]: DNS-SD initialization
failed: Daemon not running
May  4 21:25:40 enzo seahorse-daemon[1426]: unsupported key server uri
scheme: ldap
May  4 21:25:40 enzo seahorse-daemon[1426]: init gpgme version 1.3.0
May  4 21:25:41 enzo pulseaudio[1475]: module-alsa-card.c: Failed to
find a working profile.
May  4 21:25:41 enzo pulseaudio[1475]: module.c: Failed to load  module
"module-alsa-card" (argument: "device_id="5"
name="platform-thinkpad_acpi"
card_name="alsa_card.platform-thinkpad_acpi" tsched=yes ignore_dB=no
card_properties="module-udev-detect.discovered=1""): initialization failed.
May  4 21:25:41 enzo polkitd(authority=local): Registered Authentication
Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name
:1.49 [/usr/libexec/polkit-gnome-authentication-agent-1], object path
/org/gnome/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8)


----- (maybe I pasted too much, this was everything from typing my
username to the Gnome-session opened, but with the "wrong" /home for
user sgw)

Some bits of additional info:

# cat /etc/pam.d/system-auth
auth		required	pam_env.so
auth		required	pam_unix.so try_first_pass likeauth nullok
auth optional pam_mount.so
auth optional pam_gnome_keyring.so

account		required	pam_unix.so

password	required	pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2
retry=3
password optional pam_gnome_keyring.so
password	required	pam_unix.so try_first_pass use_authtok nullok sha512
shadow
session		required	pam_limits.so
session optional pam_gnome_keyring.so auto_start
session		required	pam_env.so
session		required	pam_unix.so
session		optional	pam_permit.so
session optional pam_mount.so



# cat /etc/security/pam_mount.conf.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
	See pam_mount.conf(5) for a description.
-->

<pam_mount>

               <!-- debug should come before everything else,
               since this file is still processed in a single pass
               from top-to-bottom -->

 <debug enable="0" />


		<!-- Volume definitions -->

<!--

<volume user="username"
path="/dev/mmcblk0p1"
mountpoint="/mnt/mmc"
fstype="auto" />

-->

<volume user="sgw"
path="/dev/mapper/VG01-crypthome"
mountpoint="/home/sgw"
fstype="crypt"
options="data=journal,commit=15"
cipher="aes-cbc-plain"
fskeypath="/etc/security/verysekrit.key"
fskeycipher="aes-256-cbc"
fskeyhash="md5" />

		<!-- pam_mount parameters: General tunables -->

<debug enable="1" />
<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions
allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />
<path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path>

<logout wait="0" hup="0" term="0" kill="0" />


		<!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />


</pam_mount>



--- I didn't change both files except for the debug-parameter ...


[root@enzo]:~ # eix pam_mount
[I] sys-auth/pam_mount
     Available versions:  (~)1.20 (~)1.21 (~)1.22 (~)1.24 (~)1.25
(~)1.25-r1 (~)1.26 (~)1.31 (~)1.32 (~)1.33 (~)2.0 {crypt}
     Installed versions:  2.0(12:45:53 04.05.2010)(crypt)
     Homepage:            http://pam-mount.sourceforge.net
     Description:         A PAM module that can mount volumes for a user
session

[root@enzo]:~ # eix cryptset
[I] sys-fs/cryptsetup
     Available versions:  0.1-r3 1.0.5-r1 1.0.6-r2 (~)1.0.7 (~)1.0.7-r1
(~)1.1.0 (~)1.1.1_rc1{tbz2} {dynamic nls selinux}
     Installed versions:  1.1.1_rc1{tbz2}(13:04:41 04.05.2010)(nls
-dynamic -selinux)
     Homepage:            http://code.google.com/p/cryptsetup/
     Description:         Tool to setup encrypted devices with dm-crypt


Thanks for any hints, Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 7603 bytes --]

On 05/04/2010 09:28 PM, Stefan G. Weichinger wrote:
> Am 04.05.2010 19:38, schrieb Stefan G. Weichinger:
> 
>> I don't yet have the whole picture ...
> 
> I did some "emerge -avuDN world", quite some packages updated even
> though I am doing "emerge -avu world" nearly every day ...
> 
> After a reboot and setting debug to 1 for pam_mount it says:
> 
> May  4 21:25:38 enzo slim: pam_mount(pam_mount.c:364): pam_mount 2.0:
> entering auth stage
> May  4 21:25:38 enzo slim: gkr-pam: invalid option: use_first_pass
> May  4 21:25:38 enzo slim: pam_unix(slim:session): session opened for
> user sgw by (uid=0)
> May  4 21:25:38 enzo slim: pam_mount(pam_mount.c:552): pam_mount 2.0:
> entering session stage
> May  4 21:25:38 enzo slim: pam_mount(misc.c:38): Session open: (uid=0,
> euid=0, gid=0, egid=0)
> May  4 21:25:38 enzo slim: pam_mount(mount.c:196): Mount info:
> globalconf, user=sgw <volume fstype="crypt" server="(null)"
> path="/dev/mapper/VG01-crypthome" mountpoint="/home/sgw"
> cipher="aes-cbc-plain" fskeypath="/etc/security/verysekrit.key"
> fskeycipher="aes-256-cbc" fskeyhash="md5"
> options="data=journal,commit=15" /> fstab=0
> May  4 21:25:38 enzo slim: command: 'mount.crypt'
> '-ocipher=aes-cbc-plain' '-ofsk_cipher=aes-256-cbc' '-ofsk_hash=md5'
> '-okeyfile=/etc/security/verysekrit.key' '-odata=journal,commit=15'
> '/dev/mapper/VG01-crypthome' '/home/sgw'
> May  4 21:25:38 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
> euid=0, gid=0, egid=0)
> May  4 21:25:38 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
> (uid=0, euid=0, gid=0, egid=0)
> May  4 21:25:40 enzo slim: pam_mount(mount.c:64): Errors from underlying
> mount program:
> May  4 21:25:40 enzo slim: pam_mount(mount.c:68):
> crypt_activate_by_passphrase: Operation not permitted
> May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:520): mount of
> /dev/mapper/VG01-crypthome failed
> May  4 21:25:40 enzo slim: command: 'pmvarrun' '-u' 'sgw' '-o' '1'
> May  4 21:25:40 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
> euid=0, gid=0, egid=0)
> May  4 21:25:40 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
> (uid=0, euid=0, gid=0, egid=0)
> May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:440): pmvarrun says
> login count is 1
> May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:642): done opening
> session (ret=0)
> May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:115): Clean global
> config (0)
> May  4 21:25:40 enzo slim: pam_mount(pam_mount.c:132): clean system
> authtok=0x80e6870 (0)
> May  4 21:25:40 enzo seahorse-daemon[1426]: DNS-SD initialization
> failed: Daemon not running
> May  4 21:25:40 enzo seahorse-daemon[1426]: unsupported key server uri
> scheme: ldap
> May  4 21:25:40 enzo seahorse-daemon[1426]: init gpgme version 1.3.0
> May  4 21:25:41 enzo pulseaudio[1475]: module-alsa-card.c: Failed to
> find a working profile.
> May  4 21:25:41 enzo pulseaudio[1475]: module.c: Failed to load  module
> "module-alsa-card" (argument: "device_id="5"
> name="platform-thinkpad_acpi"
> card_name="alsa_card.platform-thinkpad_acpi" tsched=yes ignore_dB=no
> card_properties="module-udev-detect.discovered=1""): initialization failed.
> May  4 21:25:41 enzo polkitd(authority=local): Registered Authentication
> Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name
> :1.49 [/usr/libexec/polkit-gnome-authentication-agent-1], object path
> /org/gnome/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8)
> 
> 
> ----- (maybe I pasted too much, this was everything from typing my
> username to the Gnome-session opened, but with the "wrong" /home for
> user sgw)
> 
> Some bits of additional info:
> 
> # cat /etc/pam.d/system-auth
> auth		required	pam_env.so
> auth		required	pam_unix.so try_first_pass likeauth nullok
> auth optional pam_mount.so
> auth optional pam_gnome_keyring.so
> 
> account		required	pam_unix.so
> 
> password	required	pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2
> retry=3
> password optional pam_gnome_keyring.so
> password	required	pam_unix.so try_first_pass use_authtok nullok sha512
> shadow
> session		required	pam_limits.so
> session optional pam_gnome_keyring.so auto_start
> session		required	pam_env.so
> session		required	pam_unix.so
> session		optional	pam_permit.so
> session optional pam_mount.so
> 
> 
> 
> # cat /etc/security/pam_mount.conf.xml
> <?xml version="1.0" encoding="utf-8" ?>
> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
> <!--
> 	See pam_mount.conf(5) for a description.
> -->
> 
> <pam_mount>
> 
>                <!-- debug should come before everything else,
>                since this file is still processed in a single pass
>                from top-to-bottom -->
> 
>  <debug enable="0" />
> 
> 
> 		<!-- Volume definitions -->
> 
> <!--
> 
> <volume user="username"
> path="/dev/mmcblk0p1"
> mountpoint="/mnt/mmc"
> fstype="auto" />
> 
> -->
> 
> <volume user="sgw"
> path="/dev/mapper/VG01-crypthome"
> mountpoint="/home/sgw"
> fstype="crypt"
> options="data=journal,commit=15"
> cipher="aes-cbc-plain"
> fskeypath="/etc/security/verysekrit.key"
> fskeycipher="aes-256-cbc"
> fskeyhash="md5" />
> 
> 		<!-- pam_mount parameters: General tunables -->
> 
> <debug enable="1" />
> <!--
> <luserconf name=".pam_mount.conf.xml" />
> -->
> 
> <!-- Note that commenting out mntoptions will give you the defaults.
>      You will need to explicitly initialize it with the empty string
>      to reset the defaults to nothing. -->
> <mntoptions
> allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
> <!--
> <mntoptions deny="suid,dev" />
> <mntoptions allow="*" />
> <mntoptions deny="*" />
> -->
> <mntoptions require="nosuid,nodev" />
> <path>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</path>
> 
> <logout wait="0" hup="0" term="0" kill="0" />
> 
> 
> 		<!-- pam_mount parameters: Volume-related -->
> 
> <mkmountpoint enable="1" remove="true" />
> 
> 
> </pam_mount>
> 
> 
> 
> --- I didn't change both files except for the debug-parameter ...
> 
> 
> [root@enzo]:~ # eix pam_mount
> [I] sys-auth/pam_mount
>      Available versions:  (~)1.20 (~)1.21 (~)1.22 (~)1.24 (~)1.25
> (~)1.25-r1 (~)1.26 (~)1.31 (~)1.32 (~)1.33 (~)2.0 {crypt}
>      Installed versions:  2.0(12:45:53 04.05.2010)(crypt)
>      Homepage:            http://pam-mount.sourceforge.net
>      Description:         A PAM module that can mount volumes for a user
> session
> 
> [root@enzo]:~ # eix cryptset
> [I] sys-fs/cryptsetup
>      Available versions:  0.1-r3 1.0.5-r1 1.0.6-r2 (~)1.0.7 (~)1.0.7-r1
> (~)1.1.0 (~)1.1.1_rc1{tbz2} {dynamic nls selinux}
>      Installed versions:  1.1.1_rc1{tbz2}(13:04:41 04.05.2010)(nls
> -dynamic -selinux)
>      Homepage:            http://code.google.com/p/cryptsetup/
>      Description:         Tool to setup encrypted devices with dm-crypt
> 
> 
> Thanks for any hints, Stefan
> 
I'm using sys-fs/cryptsetup-1.1.1_rc1 since 02.05.2010 and didn't have
any issues.
Please decrypt your partition from the command line, so we can see if it
is a cryptsetup/luks/kernel problem or a pam_mount problem.

Cmdline should something like:
$ sudo cryptsetup -d /etc/security/verysekrit.key luksOpen
/dev/mapper/VG01-crypthome myhome
Which should create /dev/mapper/myhome.

Bye,
Daniel


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Stefan G. Weichinger]

Am 04.05.2010 23:24, schrieb Daniel Troeder:

> I'm using sys-fs/cryptsetup-1.1.1_rc1 since 02.05.2010 and didn't have
> any issues.
> Please decrypt your partition from the command line, so we can see if it
> is a cryptsetup/luks/kernel problem or a pam_mount problem.
> 
> Cmdline should something like:
> $ sudo cryptsetup -d /etc/security/verysekrit.key luksOpen
> /dev/mapper/VG01-crypthome myhome
> Which should create /dev/mapper/myhome.

My user sgw is currently not allowed to sudo this (should it be? it
never was).

And for root it says "Kein Schlüssel mit diesem Passsatz verfügbar."
(german) which should be "No key available with this passphrase." in
english.

Thanks, Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On 05/05/2010 06:42 AM, Stefan G. Weichinger wrote:
> Am 04.05.2010 23:24, schrieb Daniel Troeder:
> 
>> I'm using sys-fs/cryptsetup-1.1.1_rc1 since 02.05.2010 and didn't have
>> any issues.
>> Please decrypt your partition from the command line, so we can see if it
>> is a cryptsetup/luks/kernel problem or a pam_mount problem.
>>
>> Cmdline should something like:
>> $ sudo cryptsetup -d /etc/security/verysekrit.key luksOpen
>> /dev/mapper/VG01-crypthome myhome
>> Which should create /dev/mapper/myhome.
> 
> My user sgw is currently not allowed to sudo this (should it be? it
> never was).
> 
> And for root it says "Kein Schlüssel mit diesem Passsatz verfügbar."
> (german) which should be "No key available with this passphrase." in
> english.
That is a message from cryptsetup. As you are using openssl to get the
key, I think the problem might be there.

I followed the guide you linked here (website is down, but google-cache
works:
http://webcache.googleusercontent.com/search?q=cache:7eaSac72CoIJ:home.coming.dk/index.php/2009/05/20/encrypted_home_partition_using_luks_pam_+encrypted_home_partition_using_luks_pam&cd=2&hl=de&ct=clnk&gl=de&client=firefox-a)
and it works for me (kernel is 2.6.33-zen2):

lvcreate -n crypttest -L 100M vg0
KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79`
echo $KEY | openssl aes-256-ecb > verysekrit.key
openssl aes-256-ecb -d -in verysekrit.key
# (aha :)
openssl aes-256-ecb -d -in verysekrit.key | cryptsetup -v --cipher
aes-cbc-plain --key-size 256 luksFormat /dev/vg0/crypttest
openssl aes-256-ecb -d -in verysekrit.key | cryptsetup luksOpen
/dev/vg0/crypttest decryptedtest
cryptsetup luksClose crypttest
# (i couldn't close it... don't know why...)

The key that cryptsetup is given to decrypt the partition is created by
openssl from the file. Please check the output of
$ openssl aes-256-ecb -d -in verysekrit.key
under both kernel - it should be identical.
BTW: You'll get your error message if you run:
$ echo notmykey | cryptsetup luksOpen /dev/vg0/crypttest decryptedtes

Bye,
Daniel




-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Stefan G. Weichinger]

Am 05.05.2010 10:00, schrieb Daniel Troeder:

> That is a message from cryptsetup. As you are using openssl to get
> the key, I think the problem might be there.

ok ....

> lvcreate -n crypttest -L 100M vg0 KEY=`tr -cd [:graph:] <
> /dev/urandom | head -c 79` echo $KEY | openssl aes-256-ecb >
> verysekrit.key openssl aes-256-ecb -d -in verysekrit.key # (aha :) 
> openssl aes-256-ecb -d -in verysekrit.key | cryptsetup -v --cipher 
> aes-cbc-plain --key-size 256 luksFormat /dev/vg0/crypttest openssl
> aes-256-ecb -d -in verysekrit.key | cryptsetup luksOpen 
> /dev/vg0/crypttest decryptedtest cryptsetup luksClose crypttest # (i
> couldn't close it... don't know why...)
> 
> The key that cryptsetup is given to decrypt the partition is created
> by openssl from the file. Please check the output of $ openssl
> aes-256-ecb -d -in verysekrit.key under both kernel - it should be
> identical. 

At first, thank you for your time and work!

Tried that. I have to admit that I don't know the decryption password
... but as far as I understand it should be the same as the
unix-password of the user sgw. pam_mount.so should read it when I log
in, correct?

With this password I get a "bad decrypt" so this explains why it fails.

Please let me repeat/point out that it is the same for 3 kernels
(2.6.32-r1, 2.6.33-r[12] ... ), so I should change the subject to stay
correct ...

> BTW: You'll get your error message if you run: $ echo
> notmykey | cryptsetup luksOpen /dev/vg0/crypttest decryptedtes

Yes, correct.

-

I really wonder what the reason is ... should I downgrade openssl?

Thanks Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

On 05/05/2010 10:42 AM, Stefan G. Weichinger wrote:
> Am 05.05.2010 10:00, schrieb Daniel Troeder:
> 
>> That is a message from cryptsetup. As you are using openssl to get 
>> the key, I think the problem might be there.
> 
> ok ....
> 
>> lvcreate -n crypttest -L 100M vg0 KEY=`tr -cd [:graph:] < 
>> /dev/urandom | head -c 79` echo $KEY | openssl aes-256-ecb > 
>> verysekrit.key openssl aes-256-ecb -d -in verysekrit.key # (aha :)
>>  openssl aes-256-ecb -d -in verysekrit.key | cryptsetup -v --cipher
>>  aes-cbc-plain --key-size 256 luksFormat /dev/vg0/crypttest
>> openssl aes-256-ecb -d -in verysekrit.key | cryptsetup luksOpen 
>> /dev/vg0/crypttest decryptedtest cryptsetup luksClose crypttest #
>> (i couldn't close it... don't know why...)
>> 
>> The key that cryptsetup is given to decrypt the partition is
>> created by openssl from the file. Please check the output of $
>> openssl aes-256-ecb -d -in verysekrit.key under both kernel - it
>> should be identical.
> 
> At first, thank you for your time and work!
> 
> Tried that. I have to admit that I don't know the decryption
> password ... but as far as I understand it should be the same as the 
> unix-password of the user sgw. pam_mount.so should read it when I
> log in, correct?
Yes. Than pam_mount man page (http://linux.die.net/man/8/pam_mount) says so.
It's actually quite verbose on the topic.

> With this password I get a "bad decrypt" so this explains why it
> fails.
If you cannot decrypt your keyfile (with openssl) then you have just
lost any way to decrypt your partition!

But there is an idea in the man page of which I didn't think: did you
maybe change your users password? If so, you need to use the old pw to
decrypt the keyfile. If you can, then you can use the new pw to encrypt
the key again (make backups of the original file).

There is also the possibility your keyfile was corrupted somehow (file
system corruption?). Do you have a backup of the keyfile (and your data:)?

BTW: a LUKS encrypted partition can have 8 keys (in so called "key
slots"), so that you can add a "fallback key" the next time, which you
store at a trusted place.

Good luck,
Daniel

> Please let me repeat/point out that it is the same for 3 kernels 
> (2.6.32-r1, 2.6.33-r[12] ... ), so I should change the subject to
> stay correct ...
> 
>> BTW: You'll get your error message if you run: $ echo notmykey |
>> cryptsetup luksOpen /dev/vg0/crypttest decryptedtes
> 
> Yes, correct.
> 
> -
> 
> I really wonder what the reason is ... should I downgrade openssl?
> 
> Thanks Stefan
> 


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Stefan G. Weichinger]

Am 05.05.2010 21:39, schrieb Daniel Troeder:

>> With this password I get a "bad decrypt" so this explains why it 
>> fails.
> If you cannot decrypt your keyfile (with openssl) then you have just 
> lost any way to decrypt your partition!
> 
> But there is an idea in the man page of which I didn't think: did
> you maybe change your users password? If so, you need to use the old
> pw to decrypt the keyfile. If you can, then you can use the new pw to
> encrypt the key again (make backups of the original file).

user-pw not changed, no ...

> There is also the possibility your keyfile was corrupted somehow
> (file system corruption?). Do you have a backup of the keyfile (and
> your data:)?

Restored the key-file from tape, no diff, no success.
I have some images as backup, would have to look closer ...

> BTW: a LUKS encrypted partition can have 8 keys (in so called "key 
> slots"), so that you can add a "fallback key" the next time, which
> you store at a trusted place.

I am pretty sure that I used several slots, yes.

-

Remember that I said: "I am not sure which HOWTO I followed" ?

What if I didn't use aes-256-ecb?

I will try some other ciphers .... ;-)

Oh my, I luv documentation :-)

S

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

[Stefan G. Weichinger]

Am 05.05.2010 22:17, schrieb Stefan G. Weichinger:

> Remember that I said: "I am not sure which HOWTO I followed" ?
> 
> What if I didn't use aes-256-ecb?

Yep. See pam_mount.conf.xml:
It's "aes-256-cbc" in my case.

I was now able to luksOpen and I have the decrypted device mounted.

Nice.

So:

the user-pw didn't change and the keyfile is OK.

So why is pam_mount unable to mount it?

I will now pull another backup and check/add fallback keys ;-)

Thanks so far, regards, Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On 05/05/2010 10:23 PM, Stefan G. Weichinger wrote:
> Am 05.05.2010 22:17, schrieb Stefan G. Weichinger:
> 
>> Remember that I said: "I am not sure which HOWTO I followed" ?
>>
>> What if I didn't use aes-256-ecb?
You don't need to supplay that information to cryptsetup, it can
(should) autodetect it. To see that info for yourself run:
$ cryptsetup luksDump /dev/mapper/VG01-crypthome

> Yep. See pam_mount.conf.xml:
> It's "aes-256-cbc" in my case.
> 
> I was now able to luksOpen and I have the decrypted device mounted.
Hooray :)


> Nice.
> 
> So:
> 
> the user-pw didn't change and the keyfile is OK.
> 
> So why is pam_mount unable to mount it?
> 
> I will now pull another backup and check/add fallback keys ;-)
There are interesting options in the cryptsetup-man page:
luksHeaderBackup and luksHeaderRestore... I think I'll add that to my
backup scripts :)


Bye,
Daniel


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Stefan G. Weichinger]

Am 06.05.2010 18:24, schrieb Daniel Troeder:
> On 05/05/2010 10:23 PM, Stefan G. Weichinger wrote:
>> Am 05.05.2010 22:17, schrieb Stefan G. Weichinger:
>>
>>> Remember that I said: "I am not sure which HOWTO I followed" ?
>>>
>>> What if I didn't use aes-256-ecb?
> You don't need to supplay that information to cryptsetup, it can
> (should) autodetect it. To see that info for yourself run:
> $ cryptsetup luksDump /dev/mapper/VG01-crypthome

But I always did when I followed your example.
Anyway, this part is solved now.

>> Yep. See pam_mount.conf.xml:
>> It's "aes-256-cbc" in my case.
>>
>> I was now able to luksOpen and I have the decrypted device mounted.
> Hooray :)

Yes :-)

Currently I run an unencrypted home on another LV.

>> Nice.
>>
>> So:
>>
>> the user-pw didn't change and the keyfile is OK.
>>
>> So why is pam_mount unable to mount it?
>>
>> I will now pull another backup and check/add fallback keys ;-)
> There are interesting options in the cryptsetup-man page:
> luksHeaderBackup and luksHeaderRestore... I think I'll add that to my
> backup scripts :)

Good idea.

The main question is still unanswered: Why does pam_mount not work
anymore with the given device/key ?

Should I file a bug?

S

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

[Stefan G. Weichinger]

Am 06.05.2010 20:38, schrieb Stefan G. Weichinger:

> The main question is still unanswered: Why does pam_mount not work
> anymore with the given device/key ?

additional digging:

I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528366

where the poster tries the underlying mount.crypt call.

I did that as well and get:

# mount.crypt -v -o
fsk_cipher=aes-256-cbc,fsk_hash=md5,keyfile=/etc/security/verysekrit.key
/dev/VG01/crypthome /mnt/gschwind
command: 'readlink' '-fn' '/dev/VG01/crypthome'
command: 'readlink' '-fn' '/mnt/gschwind'
Password:
mount.crypt(crypto-dmc.c:144): Using _dev_dm_0 as dmdevice name
crypt_activate_by_passphrase: Operation not permitted


which is in fact the error pam_mount throws up :

pam_mount(mount.c:64): Errors from underlying mount program:
pam_mount(mount.c:68): crypt_activate_by_passphrase: Operation not permitted

Downgrade pam_mount from 2.1 to 2.0 ... same error.

But it works with pam_mount 1.33 !

I don't know which old bugs I reintroduce to my system by doing this ;-)

I think I am gonna file a bug for this now.

Stefan

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

[Stefan G. Weichinger]

Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:

> I think I am gonna file a bug for this now.

http://bugs.gentoo.org/show_bug.cgi?id=318865

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

[Stefan G. Weichinger]

Am 07.05.2010 16:24, schrieb Stefan G. Weichinger:
> Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:
> 
>> I think I am gonna file a bug for this now.
> 
> http://bugs.gentoo.org/show_bug.cgi?id=318865

Aside from the potential bug:

As I store the "verysekrit.key" on the same hdd as the encrypted device
and use the rather simple shadowed password to decrypt that key ...
isn't that just plain stupid?

The overall security is just as good as my password.
Cracking it with john opens the key to decrypting the LUKS-volume ...

Yes, if I would store the key on another volume (stick or something) as
mentioned in that howto it would make sense but in my case ...

*scratches head* ;-)

Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On 05/07/2010 11:14 PM, Stefan G. Weichinger wrote:
> Am 07.05.2010 16:24, schrieb Stefan G. Weichinger:
>> Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:
>> 
>>> I think I am gonna file a bug for this now.
>> 
>> http://bugs.gentoo.org/show_bug.cgi?id=318865
> 
> Aside from the potential bug:
> 
> As I store the "verysekrit.key" on the same hdd as the encrypted
> device and use the rather simple shadowed password to decrypt that
> key ... isn't that just plain stupid?
> 
> The overall security is just as good as my password. Cracking it with
> john opens the key to decrypting the LUKS-volume ...
> 
> Yes, if I would store the key on another volume (stick or something)
> as mentioned in that howto it would make sense but in my case ...
> 
> *scratches head* ;-)
> 
> Stefan
I prefer to encrypt my entire harddisk. Well - a hugh partition (excl.
only Windows and Solaris :) which I encrypt, then the decrypted
partition is used as a PV for LVM and all OS and partitions an in LVs.
This way I have to type in the password to decrypt the PV once, and all
LVs are decrypted. Then I have to use a second PW to login of course. As
all Linux destros support encrypted roots and LVM nowadays I have
Gentoo, Fedora and Ubuntu all in the same VG. The speed disadvantage is
small, as my CPU+RAM is so much faster than the HDD. But in terms of
security it's better to have everything encrypted, because it makes it
more difficult to manipulate your system to get the key (the kernel is
still unencrypted), and no possibly private information can be obtained
from /tmp and /var. I compile all needed modules into the kernel, so I
don't need to recreate my initrd for every new kernel.

Bye,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[walt]

On 05/04/2010 10:38 AM, Stefan G. Weichinger wrote:
> Am 04.05.2010 18:54, schrieb walt:
>
>>> pam_mount(mount.c): crypt_activate_by_passphrase: Operation not
>>> permitted
>>
>> I don't have a pam_mount, where does it come from?  Perhaps it needs
>> a reference to pam_ssh.so?
>
> What do you mean with "where does it come from?" ?
>
> It's in portage ...

Okay, I'm assuming pam_mount.so and mount.crypt come from the sys-auth/
pam_mount package but I can't check because all of those packages are
masked by the ~x86 keyword at the moment.

> Could it be the case that my current setup somehow uses "the new API"
> which isn't available yet in some package?
>
> I don't yet have the whole picture ...

Daniel knows more than I do about this subject, so I recommend that you
follow his advice.  However, all of the pam_mount packages being masked
at the same time makes me suspect that not everything is working exactly
as it should.  I'll follow this thread, hoping to learn more.

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

[Jan Engelhardt]

[Replying to 
http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 ]

On 2010-05-05 08:00:43 GMT, Daniel Troeder wrote:
>On 05/05/2010 06:42 AM, Stefan G. Weichinger wrote:
>> Am 04.05.2010 23:24, schrieb Daniel Troeder:
>> 
>>> I'm using sys-fs/cryptsetup-1.1.1_rc1 since 02.05.2010 and didn't have
>>> any issues.
>>> Please decrypt your partition from the command line, so we can see if it
>>> is a cryptsetup/luks/kernel problem or a pam_mount problem.
>>>
>>> Cmdline should something like:
>>> $ sudo cryptsetup -d /etc/security/verysekrit.key luksOpen
>>> /dev/mapper/VG01-crypthome myhome
>>> Which should create /dev/mapper/myhome.
>> 
>> My user sgw is currently not allowed to sudo this (should it be? it
>> never was).
>> 
>> And for root it says "Kein Schlüssel mit diesem Passsatz verfügbar."
>> (german) which should be "No key available with this passphrase." in
>> english.
>That is a message from cryptsetup. As you are using openssl to get the
>key, I think the problem might be there.
>
>I followed the guide you linked here (website is down, but google-cache
>works:
>http://webcache.googleusercontent.com/search?q=cache:7eaSac72CoIJ:home.coming.dk/index.php/2009/05/20/encrypted_home_partition_using_luks_pam_+encrypted_home_partition_using_luks_pam&cd=2&hl=de&ct=clnk&gl=de&client=firefox-a)
>and it works for me (kernel is 2.6.33-zen2):
>
>lvcreate -n crypttest -L 100M vg0
>KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79`
>echo $KEY | openssl aes-256-ecb > verysekrit.key
>openssl aes-256-ecb -d -in verysekrit.key

In my personal opinion, both the quality of shell commands and key
generation is suboptimal. What makes it bad is that people follow it.

First, it generates a key which does not exploit the entire space. 
People claim it's because they want an ASCII readout, but frankly, you 
get the same with `hexdump -C`.

Second, it's using echo without the -n parameter, thus implicitly 
inserting a newline into the key -- which is the cause for yoru observed 
mounting problems.

Third, because you are passing the key via stdin into cryptsetup, it 
only uses the first line of whatever you pipe into it; whereas pam_mount 
uses the entire keyfile as it is supposed to be.

(Fourth, the howto suggests ECB, which, well, looks rather weak 
considering the ECB's Tux picture on Wikipedia.)

All of that should be in doc/bugs.txt, and mount.crypt even warns about 
ECB. You really cannot ignore seeing that.

Phew!

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

[Stefan G. Weichinger]

Am 16.05.2010 14:36, schrieb Jan Engelhardt:
> [Replying to 
> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 
> ]
> 
> In my personal opinion, both the quality of shell commands and key 
> generation is suboptimal. What makes it bad is that people follow 
> it.
> 
> First, it generates a key which does not exploit the entire space. 
> People claim it's because they want an ASCII readout, but frankly, 
> you get the same with `hexdump -C`.
> 
> Second, it's using echo without the -n parameter, thus implicitly 
> inserting a newline into the key -- which is the cause for yoru 
> observed mounting problems.
> 
> Third, because you are passing the key via stdin into cryptsetup, it 
> only uses the first line of whatever you pipe into it; whereas 
> pam_mount uses the entire keyfile as it is supposed to be.
> 
> (Fourth, the howto suggests ECB, which, well, looks rather weak 
> considering the ECB's Tux picture on Wikipedia.)
> 
> All of that should be in doc/bugs.txt, and mount.crypt even warns 
> about ECB. You really cannot ignore seeing that.
> 
> Phew!

Jan, thanks for your suggestions.

I created a new LUKS-volume and tried to avoid all the mentioned
pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.

The new volume is not mounted with pam_mount-2.1, but mounted OK with
pam_mount-1.33.

And, btw, as mentioned in the original thread, I use CBC, not ECB ;-)

-- Your CCing Daniel didn't work maybe, wrong address, I corrected it
for this reply)

-- I CC: hanno@gentoo.org to link to the gentoo bug

http://bugs.gentoo.org/show_bug.cgi?id=318865

Thanks, regards, Stefan

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote:
> Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>> [Replying to 
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 
>> ]
>>
>> In my personal opinion, both the quality of shell commands and key 
>> generation is suboptimal. What makes it bad is that people follow 
>> it.
>>
>> First, it generates a key which does not exploit the entire space. 
>> People claim it's because they want an ASCII readout, but frankly, 
>> you get the same with `hexdump -C`.
>>
>> Second, it's using echo without the -n parameter, thus implicitly 
>> inserting a newline into the key -- which is the cause for yoru 
>> observed mounting problems.
>>
>> Third, because you are passing the key via stdin into cryptsetup, it 
>> only uses the first line of whatever you pipe into it; whereas 
>> pam_mount uses the entire keyfile as it is supposed to be.
>>
>> (Fourth, the howto suggests ECB, which, well, looks rather weak 
>> considering the ECB's Tux picture on Wikipedia.)
>>
>> All of that should be in doc/bugs.txt, and mount.crypt even warns 
>> about ECB. You really cannot ignore seeing that.
>>
>> Phew!
> 
> Jan, thanks for your suggestions.
> 
> I created a new LUKS-volume and tried to avoid all the mentioned
> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.
> 
> The new volume is not mounted with pam_mount-2.1, but mounted OK with
> pam_mount-1.33.
> 
> And, btw, as mentioned in the original thread, I use CBC, not ECB ;-)
> 
> -- Your CCing Daniel didn't work maybe, wrong address, I corrected it
> for this reply)
> 
> -- I CC: hanno@gentoo.org to link to the gentoo bug
> 
> http://bugs.gentoo.org/show_bug.cgi?id=318865
> 
> Thanks, regards, Stefan
> 
Hello :)

In a more general discussion I wonder what the advantage of using a SSL
encrypted key for HDD-encryption is.

As the SSL-keyfile is as well protected as the password to decrypt it is
"difficult", so would be a directly encrypted HDD with the same password
- or not?

If this assumption is correct, then I think the direct approach would be
better, as in "less complexity - less errors".

<For the paranoid>
I think it is much easier to hide a trojan/keylogger on an unencrypted
root-partition than in an initramfs - and not be detected. (Both is easy
to do, but the latter can be detected easier.) Unfortunately that
detection is never done... after opening the root-dev some form of
file-/partition-manipulation check should run. Though the kernel could
be already compromised... Only a secure boot-path like with TCG is
really secure... well this is only if you fear strong attackers, and not
only loosing your notebook :) I head that really strong attackers would
hide a keylogger beneath your keyboard... but if you have that kind of
opponent, then you really have other problems too :)
</For the paranoid>

Anyway - if your /tmp is not encrypted you should put it on a ram-disk:
gives you speed and privacy in case of robbery. Also important is to
have the screensaver lock the screen.

On a technical note: I use "xts" as I read it's a good (although new) algo.

Bye,
Daniel


BTW: No need to CC mailing list mails to me - I'll read and reply the
ML-thread when I have time :)


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Jan Engelhardt]

On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote:
>Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>> [Replying to 
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 
>> ]
>> 
>> Second, it's using echo without the -n parameter, thus implicitly 
>> inserting a newline into the key -- which is the cause for yoru 
>> observed mounting problems.
>> 
>> Third, because you are passing the key via stdin into cryptsetup, it 
>> only uses the first line of whatever you pipe into it; whereas 
>> pam_mount uses the entire keyfile as it is supposed to be.
>>[...]
>Jan, thanks for your suggestions.
>
>I created a new LUKS-volume and tried to avoid all the mentioned
>pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.

To be sure, use

	openssl -d ... | hexdump -C

to detect newlines in the key. The shell has far too many occasions
where \n gets stripped or added.

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

[Stefan G. Weichinger]

Am 18.05.2010 15:05, schrieb Jan Engelhardt:
> 
> On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote:
>> Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>>> [Replying to 
>>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 
>>> ]
>>>
>>> Second, it's using echo without the -n parameter, thus implicitly 
>>> inserting a newline into the key -- which is the cause for yoru 
>>> observed mounting problems.
>>>
>>> Third, because you are passing the key via stdin into cryptsetup, it 
>>> only uses the first line of whatever you pipe into it; whereas 
>>> pam_mount uses the entire keyfile as it is supposed to be.
>>> [...]
>> Jan, thanks for your suggestions.
>>
>> I created a new LUKS-volume and tried to avoid all the mentioned
>> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.
> 
> To be sure, use
> 
> 	openssl -d ... | hexdump -C
> 
> to detect newlines in the key. The shell has far too many occasions
> where \n gets stripped or added.

Thanks for the hint.

Could you please show me an example how it should look like and what to
look for?

I get several lines of output, that seems bad ... ?

Maybe I didn't get all the steps right, could be.

Do you know any howto where it is done "the right way"?

Thanks, Stefan

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

[Jan Engelhardt]

On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote:
>> 
>> To be sure, use
>> 
>> 	openssl -d ... | hexdump -C
>> 
>> to detect newlines in the key. The shell has far too many occasions
>> where \n gets stripped or added.
>
>Thanks for the hint.
>
>Could you please show me an example how it should look like and what to
>look for?

In case the key is a suboptimal ascii-only key, it looks like this.

offset    bytes broken up                                   visual represent.
00000000  35 34 28 5e 52 69 4c 22  3c 72 4c 35 35 27 70 32  |54(^RiL"<rL55'p2|
00000010  39 59 48 21 3b 50 2e 25  52 6e 27 4f 4d 51 42 6b  |9YH!;P.%Rn'OMQBk|
00000020  34 43 38 76 4e 49 51 24  3f 5e 42 63 2f 6c 2d 76  |4C8vNIQ$?^Bc/l-v|
00000030  34 7d 4d 6a 50 5c 41 3c  3f 70 76 67 22 57 21 6b  |4}MjP\A<?pvg"W!k|
00000040  77 78 5c 24 23 5e 2e 56  7a 56 24 5a 4f 7e 6a     |wx\$#^.VzV$ZO~j|
0000004f

If there were a newline, one of the bytes would be 0a.

>Do you know any howto where it is done "the right way"?

The right and easy way is to just use the supplied pmt-ehd(8) tool,
which works both interactively and non-interactively, depending on
whether it's called with enough arguments or not, so there's something
for everybody's flavor.
It does not do LUKS yet as of pam_mount 2.2, though. Guess my
todo list gets longer..

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

[Stefan G. Weichinger]

Am 18.05.2010 18:04, schrieb Jan Engelhardt:
> 
> On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote:
>>>
>>> To be sure, use
>>>
>>> 	openssl -d ... | hexdump -C
>>>
>>> to detect newlines in the key. The shell has far too many occasions
>>> where \n gets stripped or added.
>>
>> Thanks for the hint.
>>
>> Could you please show me an example how it should look like and what to
>> look for?
> 
> In case the key is a suboptimal ascii-only key, it looks like this.
> 
> offset    bytes broken up                                   visual represent.
> 00000000  35 34 28 5e 52 69 4c 22  3c 72 4c 35 35 27 70 32  |54(^RiL"<rL55'p2|
> 00000010  39 59 48 21 3b 50 2e 25  52 6e 27 4f 4d 51 42 6b  |9YH!;P.%Rn'OMQBk|
> 00000020  34 43 38 76 4e 49 51 24  3f 5e 42 63 2f 6c 2d 76  |4C8vNIQ$?^Bc/l-v|
> 00000030  34 7d 4d 6a 50 5c 41 3c  3f 70 76 67 22 57 21 6b  |4}MjP\A<?pvg"W!k|
> 00000040  77 78 5c 24 23 5e 2e 56  7a 56 24 5a 4f 7e 6a     |wx\$#^.VzV$ZO~j|
> 0000004f
> 
> If there were a newline, one of the bytes would be 0a.

Will check ...

>> Do you know any howto where it is done "the right way"?
> 
> The right and easy way is to just use the supplied pmt-ehd(8) tool,
> which works both interactively and non-interactively, depending on
> whether it's called with enough arguments or not, so there's something
> for everybody's flavor.
> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
> todo list gets longer..

:-)

But given the fact that I store the key on the same hard-disk with the
shadowed user-pw I could also leave that openssl-part straight away,
correct?? seems the same level of (in)security to me ...

thank you, Stefan

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

[Jan Engelhardt]

On Tuesday 2010-05-18 18:56, Stefan G. Weichinger wrote:
>
>>> Do you know any howto where it is done "the right way"?
>> 
>> The right and easy way is to just use the supplied pmt-ehd(8) tool,
>> which works both interactively and non-interactively, depending on
>> whether it's called with enough arguments or not, so there's something
>> for everybody's flavor.
>> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
>> todo list gets longer..
>
>:-)
>
>But given the fact that I store the key on the same hard-disk with the
>shadowed user-pw I could also leave that openssl-part straight away,
>correct?? seems the same level of (in)security to me ...

Yes. The point of keyfiles is to be able to change the password on
a volume.

Without a keyfile, a crypto program would take the password, hash it
somehow, and you get your AES key. Changing the password means having
a different AES key, meaning decrypting the disk will yield a
different result. In other words, changing the password would require
at least reading the old data, reencrypting it and writing it again.
Takes time.

With a keyfile, you retain the same AES key all the time, and encrypt
the AES key itself - reencrypting the AES key is quick, as it's
only some xyz bits, not terabytes.

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

[Stefan G. Weichinger]

Am 18.05.2010 19:57, schrieb Jan Engelhardt:

>> But given the fact that I store the key on the same hard-disk with the
>> shadowed user-pw I could also leave that openssl-part straight away,
>> correct?? seems the same level of (in)security to me ...
> 
> Yes. The point of keyfiles is to be able to change the password on
> a volume.
> 
> Without a keyfile, a crypto program would take the password, hash it
> somehow, and you get your AES key. Changing the password means having
> a different AES key, meaning decrypting the disk will yield a
> different result. In other words, changing the password would require
> at least reading the old data, reencrypting it and writing it again.
> Takes time.
> 
> With a keyfile, you retain the same AES key all the time, and encrypt
> the AES key itself - reencrypting the AES key is quick, as it's
> only some xyz bits, not terabytes.

Ok, I see. So my current setup with one disk only and SSL-generated
keyfile does not add security but flexibility (being able to switch
passwords more quickly).

Do you see a way of getting this working with my current packages:

pam_mount-2.1
sys-fs/cryptsetup-1.1.1_rc2

and LUKS ... ?

As mentioned the old keyfile works with pam_mount-1.33, when I check the
changelog at

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/pam_mount/ChangeLog?view=markup

this is a package from 10 Jan 2010, so maybe it wouldn't be too risky to
just mask >pam_mount-1.33

-

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)?

Thanks for your time, Stefan

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

[Stefan G. Weichinger]

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 ...
I masked pam_mount-2.x again ...

Stefan

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

[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.

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

[Stefan G. Weichinger]

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

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

[Jan Engelhardt]

yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
>
>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`

Well, I'm not going to blame you yet, but the shell is pretty
binary-unsafe -- and you have just invoked that voodoo again.

# head -c79 /dev/urandom >t-crypt.ukey; \
  hexdump -C <t-crypt.ukey; \
  KEY=$(cat t-crypt.ukey); \
  echo -n "$KEY" | hexdump -C; \
  echo -n "$KEY" | wc;
00000000  a4 b2 c8 a0 4f c9 00 37  66 f3 0c 20 2d 5c 05 e7  |....O..7f.. -\..|
00000010  cd 5e 5d 00 5d e1 18 2a  1a 8b 2d 41 22 e7 66 0e  |.^].]..*..-A".f.|
00000020  b0 a3 1d 41 1e 23 1d 00  f8 b2 b2 bc 34 28 94 fe  |...A.#......4(..|
00000030  ba 0f 45 11 b5 c6 d8 a1  ca c2 ec 08 5e 48 d4 7f  |..E.........^H..|
00000040  17 a8 75 af ef ef f1 7a  0f 2f bf 64 c2 3a 9c     |..u....z./.d.:.|
0000004f

00000000  a4 b2 c8 a0 4f c9 37 66  f3 0c 20 2d 5c 05 e7 cd  |....O.7f.. -\...|
00000010  5e 5d 5d e1 18 2a 1a 8b  2d 41 22 e7 66 0e b0 a3  |^]]..*..-A".f...|
00000020  1d 41 1e 23 1d f8 b2 b2  bc 34 28 94 fe ba 0f 45  |.A.#.....4(....E|
00000030  11 b5 c6 d8 a1 ca c2 ec  08 5e 48 d4 7f 17 a8 75  |.........^H....u|
00000040  af ef ef f1 7a 0f 2f bf  64 c2 3a 9c              |....z./.d.:.|
0000004c
      0       2      76

So what was once 79 bytes has been reduced to 76 by means of the $()
or backtick operator.

Not a problem for the crypto utilities per se, but I wanted to point out 
that you are effectively only having a 76-long key here. The chance to 
get a key shorter than the requested 79 is 27%.

># 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

Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is 
moot. Instead....

[fkey is the unencrypted one]

# cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \
  cryptsetup --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey 
Key slot 0 unlocked.


And you thought that doc/bugs.txt described all cryptsetup CLI oddities.

*facepalm*

ANYWAY.


If I proceed with this luks container now, all succeeds:

# mkfs.ext4 /dev/mapper/x94 
mke2fs 1.41.9 (22-Aug-2009)
...
# cryptsetup remove x94

First, let's see if raw passthrough works:

# ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt
command: 'readlink' '-fn' '/dev/loop94' 
command: 'readlink' '-fn' '/mnt' 
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' 
# df /mnt
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop94              62465      5365     53875  10% /mnt
# PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt


Now the openssl-encrypted file:

# ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt
command: 'readlink' '-fn' '/dev/loop94' 
command: 'readlink' '-fn' '/mnt' 
Password: 
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' 
# df /mnt
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop94              62465      5365     53875  10% /mnt


Match?

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

[Stefan G. Weichinger]

Am 18.05.2010 23:16, schrieb Jan Engelhardt:
> yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
>> 
>> 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`
> 
> Well, I'm not going to blame you yet, but the shell is pretty 
> binary-unsafe -- and you have just invoked that voodoo again.
> 
> # head -c79 /dev/urandom >t-crypt.ukey; \ hexdump -C <t-crypt.ukey;
> \ KEY=$(cat t-crypt.ukey); \ echo -n "$KEY" | hexdump -C; \ echo -n
> "$KEY" | wc; 00000000  a4 b2 c8 a0 4f c9 00 37  66 f3 0c 20 2d 5c 05
> e7  |....O..7f.. -\..| 00000010  cd 5e 5d 00 5d e1 18 2a  1a 8b 2d 41
> 22 e7 66 0e  |.^].]..*..-A".f.| 00000020  b0 a3 1d 41 1e 23 1d 00  f8
> b2 b2 bc 34 28 94 fe  |...A.#......4(..| 00000030  ba 0f 45 11 b5 c6
> d8 a1  ca c2 ec 08 5e 48 d4 7f  |..E.........^H..| 00000040  17 a8 75
> af ef ef f1 7a  0f 2f bf 64 c2 3a 9c     |..u....z./.d.:.| 0000004f
> 
> 00000000  a4 b2 c8 a0 4f c9 37 66  f3 0c 20 2d 5c 05 e7 cd
> |....O.7f.. -\...| 00000010  5e 5d 5d e1 18 2a 1a 8b  2d 41 22 e7 66
> 0e b0 a3  |^]]..*..-A".f...| 00000020  1d 41 1e 23 1d f8 b2 b2  bc 34
> 28 94 fe ba 0f 45  |.A.#.....4(....E| 00000030  11 b5 c6 d8 a1 ca c2
> ec  08 5e 48 d4 7f 17 a8 75  |.........^H....u| 00000040  af ef ef f1
> 7a 0f 2f bf  64 c2 3a 9c              |....z./.d.:.| 0000004c 0
> 2      76
> 
> So what was once 79 bytes has been reduced to 76 by means of the $() 
> or backtick operator.
> 
> Not a problem for the crypto utilities per se, but I wanted to point
> out that you are effectively only having a 76-long key here. The
> chance to get a key shorter than the requested 79 is 27%.
> 
>> # 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
> 
> Turns out cryptsetup has yet another oddity. With LUKS, --key-file=-
> is moot. Instead....
> 
> [fkey is the unencrypted one]
> 
> # cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \ cryptsetup
> --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey Key slot 0
> unlocked.
> 
> 
> And you thought that doc/bugs.txt described all cryptsetup CLI
> oddities.
> 
> *facepalm*
> 
> ANYWAY.
> 
> 
> If I proceed with this luks container now, all succeeds:
> 
> # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... #
> cryptsetup remove x94
> 
> First, let's see if raw passthrough works:
> 
> # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as
> dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
>  # df /mnt Filesystem           1K-blocks      Used Available Use%
> Mounted on /dev/loop94              62465      5365     53875  10%
> /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt
> 
> 
> Now the openssl-encrypted file:
> 
> # ./mount.crypt -vo
> keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
> _dev_loop94 as dmdevice name command: 'mount' '-n'
> '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
> 1K-blocks      Used Available Use% Mounted on /dev/loop94
> 62465      5365     53875  10% /mnt
> 
> 
> Match?

Frankly: dunno ;-)
Yes, I am able to follow and understand in general so far ... but ...

Assuming that "I am too stupid": Where is the how-to-do-it?

So far the only thing I really understood "You are doing it wrong".

But where is the "Do it this way and you are safe" ?

I wouldn't post here if I were competent enough to know all these details.

Concerning encryption I am at the USER-level, you know for sure ;-)

Just trying to feed back my problems to maybe detect bugs or my mistakes.

Stefan

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

[Jan Engelhardt]

On Tuesday 2010-05-18 23:49, Stefan G. Weichinger wrote:

>> # ./mount.crypt -vo
>> keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
>> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
>> '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
>> _dev_loop94 as dmdevice name command: 'mount' '-n'
>> '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
>> 1K-blocks      Used Available Use% Mounted on /dev/loop94
>> 62465      5365     53875  10% /mnt
>> 
>> Match?
>
>Frankly: dunno ;-)
>Yes, I am able to follow and understand in general so far ... but ...

Right now it's more a case of "let's do it and compare results"
than having to thoroughly understand when and where cryptsetup
chops off a byte and pads another.

That went fine, up to

># mount the new fs
>mount /dev/mapper/newhome /mnt/gschwind
>all this worked OK so far, but not with pam_mount.
>OK?

OK, but don't stop there. pam_mount really just ultimatively runs
mount.crypt; and it tells you that it does by means of syslog
(with enabled debug=1 of course).

command: 'mount.crypt' '-ofsk....

And that is what you can run from shell, which eliminates
pam_mount from the path and only leaves the usual suspects.

Keep on it, marine!


>Assuming that "I am too stupid": Where is the how-to-do-it?
>So far the only thing I really understood "You are doing it wrong".
>But where is the "Do it this way and you are safe" ?

http://archives.gentoo.org/gentoo-user/msg_e80d6e5a662b7595a2a8a70a0fa166dd.xml
was basically it: pmt-ehd and you're safe. Short of the current
...missing feature though, mentioned in that same mail.

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

[Stefan G. Weichinger]

Am 19.05.2010 00:23, schrieb Jan Engelhardt:

> OK, but don't stop there. pam_mount really just ultimatively runs 
> mount.crypt; and it tells you that it does by means of syslog (with
> enabled debug=1 of course).
> 
> command: 'mount.crypt' '-ofsk....

Sorry, I don't see that in my logs (yep, debug=1).


May 20 12:18:03 enzo slim: pam_mount(pam_mount.c:364): pam_mount 2.1:
entering auth stage
May 20 12:18:03 enzo slim: pam_mount(pam_mount.c:552): pam_mount 2.1:
entering session stage
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): Session open: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:03 enzo slim: pam_mount(mount.c:196): Mount info:
globalconf, user=sgw <volume fstype="crypt" server="(null)"
path="/dev/mapper/VG01-crypthome" mountpoint="/home/sgw"
cipher="aes-cbc-plain" fskeypath="/etc/security/verysekrit.key"
fskeycipher="aes-256-cbc" fskeyhash="md5"
options="data=journal,commit=15" /> fstab=0
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May 20 12:18:12 enzo slim: pam_mount(mount.c:64): Errors from underlying
mount program:
May 20 12:18:12 enzo slim: pam_mount(mount.c:68):
crypt_activate_by_passphrase: Operation not permitted
May 20 12:18:14 enzo slim: pam_mount(pam_mount.c:520): mount of
/dev/mapper/VG01-crypthome failed
May 20 12:18:14 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:14 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May 20 12:18:15 enzo slim: pam_mount(pam_mount.c:440): pmvarrun says
login count is 1
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:642): done opening
session (ret=0)
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:115): Clean global
config (0)
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:132): clean system
authtok=0x80bdac0 (0)



> And that is what you can run from shell, which eliminates pam_mount
> from the path and only leaves the usual suspects.
> 
> Keep on it, marine!

I try ;-)   *sigh*

Stefan

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

[Stefan G. Weichinger]

Am 20.05.2010 12:25, schrieb Stefan G. Weichinger:
> Am 19.05.2010 00:23, schrieb Jan Engelhardt:
> 
>> OK, but don't stop there. pam_mount really just ultimatively runs 
>> mount.crypt; and it tells you that it does by means of syslog (with
>> enabled debug=1 of course).
>>
>> command: 'mount.crypt' '-ofsk....
> 
> Sorry, I don't see that in my logs (yep, debug=1).

debug=2 didn't show anything new, btw.

--

Trying pmt-ehd for a change:

# pmt-ehd -f /dev/VG01/sgwcrypt -p /etc/security/sgwcrypt.enc -h md5 -D
-s 25000

Creating a new container at /dev/VG01/sgwcrypt
/dev/VG01/sgwcrypt is a symlink and points to ../dm-2
Do you really want to overwrite /dev/VG01/sgwcrypt? (y/n)
y
Writing random data to container
Password:
Reenter password:
Using openssl cipher "aes-256-cbc" and hash "md5"
ehd(crypto-dmc.c:144): Using _dev_VG01_sgwcrypt as dmdevice name
crypt_activate: No such file or directory

Oh my ...

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

[Eray Aslan]

On Tue, May 18, 2010 at 08:57:58PM +0200, Stefan G. Weichinger wrote:
> Am 18.05.2010 19:57, schrieb Jan Engelhardt:
> Ok, I see. So my current setup with one disk only and SSL-generated
> keyfile does not add security but flexibility (being able to switch
> passwords more quickly).

Keep the keyfile in a usb-stick if you can.  Decrypting the hard disk
will require both the usb-stick and the password, i.e. two factor
authentication.

-- 
Eray

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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

On 05/18/2010 07:57 PM, Jan Engelhardt wrote:
> 
> On Tuesday 2010-05-18 18:56, Stefan G. Weichinger wrote:
>>
>>>> Do you know any howto where it is done "the right way"?
>>>
>>> The right and easy way is to just use the supplied pmt-ehd(8) tool,
>>> which works both interactively and non-interactively, depending on
>>> whether it's called with enough arguments or not, so there's something
>>> for everybody's flavor.
>>> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
>>> todo list gets longer..
>>
>> :-)
>>
>> But given the fact that I store the key on the same hard-disk with the
>> shadowed user-pw I could also leave that openssl-part straight away,
>> correct?? seems the same level of (in)security to me ...
> 
> Yes. The point of keyfiles is to be able to change the password on
> a volume.
> 
> Without a keyfile, a crypto program would take the password, hash it
> somehow, and you get your AES key. Changing the password means having
> a different AES key, meaning decrypting the disk will yield a
> different result. In other words, changing the password would require
> at least reading the old data, reencrypting it and writing it again.
> Takes time.
> 
> With a keyfile, you retain the same AES key all the time, and encrypt
> the AES key itself - reencrypting the AES key is quick, as it's
> only some xyz bits, not terabytes.

That's not true for LUKS. This is one of the nice things about it:
Multiple keys can be used on a volume, and it is possible to change the
passwords in a safe way. (You have 8 "key slots", each can be used to
decrypt the volume. To change a PW use a new slot, then remove the old
one.) The trick here is that LUKS does by itself safely, what you are
trying to do with the SSL-key in a hackish way (no offense). The key
setup scheme is a modified TKS1 (nice Paper:
http://clemens.endorphin.org/TKS1-draft.pdf - read section 2 "Two Level
Encryption") which uses the keys in the key slots to encrypt a master
key which is used to encrypt the volume. So the only key(s) you ever
change is the key(s) encrypting the master key.

LUKS really does by itself already, what you are doing :)

So I'm pretty sure, that it is safer to use the LUKS key setup (that has
been peer-reviewed by security experts), than a self written shell script.

Bye,
Daniel


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]