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
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,
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'
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 --
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
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
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
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
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
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
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
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)?
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.
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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:]
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:
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
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
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
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
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
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
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
36 matches
Mail list logo
