[dm-crypt] problems mounting encrypted drive on reboot

[dm-crypt] problems mounting encrypted drive on reboot

[Jerry Lowry]

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

Hi,

I have created an encrypted drive using the following commands:

#>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file 
create /dev/mapper/testcui /dev/sdb

#>mkfs.ext4 /dev/mapper/testcui

I did this all at single user level.  running centos 7 on a VM.

this all work well until I reboot the system and then it fails to mount 
the device and drops down it to emergency mode.  This is the journalctl 
output I get. ( yeah I know about the acls on the key file )  device 
name  "testcui"

Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for 
/dev/mapper/testcui...
-- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has 
begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-cryptsetup@-dev-mapper-testcui.service has begun 
starting up.
Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is 
world-readable. This is not a good idea!
Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode 
cbc-essiv:sha256, key size 256 bits for device /dev/sdb.
Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: *Failed to activate 
with key file '/etc/keys': Invalid argument*
Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests to 
Plymouth.

What is the invalid argument that it is complaining about?

Once in emergency mode I can :

#>cryptsetup create testcui /dev/sdb

( passcode)

And it continues just fine.

-- crypttab --

# test disk
#
/dev/mapper/testcui  /dev/sdb /etc/keys plain

--fstab--

#
# /etc/fstab
# Created by anaconda on Tue Dec 15 12:05:51 2015
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 / xfs     defaults        1 1
UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot xfs     defaults        1 2
UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap swap    defaults        0 0
/dev/mapper/testcui    /cui        ext4    defaults    1 2

jerry

-- 

---------------------------------------------------------------------------
Jerold Lowry
Principal Network/Systems Engineer
Engineering Design Team (EDT), Inc. a HEICO company
3423 NW John Olsen Pl
Hillsboro, Oregon 97124 (U.S.A.)
Phone: 503-690-1234 / 800-435-4320
Fax: 503-690-1243
Web: _www.edt.com <http://www.edt.com/>_



[-- Attachment #2: Type: text/html, Size: 5020 bytes --]

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Arno Wagner]

Hi,

looks to me like you need to complain to the systemd-people,
not to us here. Good luck with that....

Regards,
Arno

On Thu, Sep 21, 2017 at 00:38:20 CEST, Jerry Lowry wrote:
>    Hi,
> 
>    I have created an encrypted drive using the following commands:
> 
>    #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file
>    create /dev/mapper/testcui /dev/sdb
> 
>    #>mkfs.ext4 /dev/mapper/testcui
> 
>    I did this all at single user level.  running centos 7 on a VM.
> 
>    this all work well until I reboot the system and then it fails to mount
>    the device and drops down it to emergency mode.  This is the journalctl
>    output I get. ( yeah I know about the acls on the key file )  device
>    name  "testcui"
> 
>    Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for
>    /dev/mapper/testcui...
>    -- Subject: Unit [1]systemd-cryptsetup@-dev-mapper-testcui.service has
>    begun start-up
>    -- Defined-By: systemd
>    -- Support:
>    [2]http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>    --
>    -- Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has begun
>    starting up.
>    Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is
>    world-readable. This is not a good idea!
>    Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode
>    cbc-essiv:sha256, key size 256 bits for device /dev/sdb.
>    Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Failed to activate
>    with key file '/etc/keys': Invalid argument
>    Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests
>    to Plymouth.
> 
>    What is the invalid argument that it is complaining about?
> 
>    Once in emergency mode I can :
> 
>    #>cryptsetup create testcui /dev/sdb
> 
>    ( passcode)
> 
>    And it continues just fine.
> 
>    -- crypttab --
> 
>    # test disk
>    #
>    /dev/mapper/testcui  /dev/sdb /etc/keys plain
> 
>    --fstab--
> 
>    #
>    # /etc/fstab
>    # Created by anaconda on Tue Dec 15 12:05:51 2015
>    #
>    # Accessible filesystems, by reference, are maintained under
>    '/dev/disk'
>    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
>    info
>    #
>    UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 /
>    xfs     defaults        1 1
>    UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot
>    xfs     defaults        1 2
>    UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap
>    swap    defaults        0 0
>    /dev/mapper/testcui    /cui        ext4    defaults    1 2
> 
>    jerry
> 
>    --
> 
>    -----------------------------------------------------------------------
>    ----
>    Jerold Lowry
>    Principal Network/Systems Engineer
>    Engineering Design Team (EDT), Inc. a HEICO company
>    3423 NW John Olsen Pl
>    Hillsboro, Oregon 97124 (U.S.A.)
>    Phone: 503-690-1234 / 800-435-4320
>    Fax: 503-690-1243
>    Web: [4]www.edt.com
> 
> References
> 
>    1. mailto:systemd-cryptsetup@-dev-mapper-testcui.service
>    2. http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>    3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service
>    4. http://www.edt.com/

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Jerry Lowry]

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

Well, I have traced the error down to cryptsetup.c, line 564. Which is 
getting a return code of less than 0 from crypt_activate_by_keyfile_offset.

So, I don't think it is the systemd folks.  Just my guess.

---------------------------------------------------------------------------
Jerold Lowry
Principal Network/Systems Engineer
Engineering Design Team (EDT), Inc. a HEICO company
3423 NW John Olsen Pl
Hillsboro, Oregon 97124 (U.S.A.)
Phone: 503-690-1234 / 800-435-4320
Fax: 503-690-1243
Web: _www.edt.com <http://www.edt.com/>_


On 9/20/2017 3:53 PM, Arno Wagner wrote:
> Hi,
>
> looks to me like you need to complain to the systemd-people,
> not to us here. Good luck with that....
>
> Regards,
> Arno
>
> On Thu, Sep 21, 2017 at 00:38:20 CEST, Jerry Lowry wrote:
>>     Hi,
>>
>>     I have created an encrypted drive using the following commands:
>>
>>     #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file
>>     create /dev/mapper/testcui /dev/sdb
>>
>>     #>mkfs.ext4 /dev/mapper/testcui
>>
>>     I did this all at single user level.  running centos 7 on a VM.
>>
>>     this all work well until I reboot the system and then it fails to mount
>>     the device and drops down it to emergency mode.  This is the journalctl
>>     output I get. ( yeah I know about the acls on the key file )  device
>>     name  "testcui"
>>
>>     Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for
>>     /dev/mapper/testcui...
>>     -- Subject: Unit [1]systemd-cryptsetup@-dev-mapper-testcui.service has
>>     begun start-up
>>     -- Defined-By: systemd
>>     -- Support:
>>     [2]https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~
>>     --
>>     -- Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has begun
>>     starting up.
>>     Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is
>>     world-readable. This is not a good idea!
>>     Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode
>>     cbc-essiv:sha256, key size 256 bits for device /dev/sdb.
>>     Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Failed to activate
>>     with key file '/etc/keys': Invalid argument
>>     Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests
>>     to Plymouth.
>>
>>     What is the invalid argument that it is complaining about?
>>
>>     Once in emergency mode I can :
>>
>>     #>cryptsetup create testcui /dev/sdb
>>
>>     ( passcode)
>>
>>     And it continues just fine.
>>
>>     -- crypttab --
>>
>>     # test disk
>>     #
>>     /dev/mapper/testcui  /dev/sdb /etc/keys plain
>>
>>     --fstab--
>>
>>     #
>>     # /etc/fstab
>>     # Created by anaconda on Tue Dec 15 12:05:51 2015
>>     #
>>     # Accessible filesystems, by reference, are maintained under
>>     '/dev/disk'
>>     # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
>>     info
>>     #
>>     UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 /
>>     xfs     defaults        1 1
>>     UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot
>>     xfs     defaults        1 2
>>     UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap
>>     swap    defaults        0 0
>>     /dev/mapper/testcui    /cui        ext4    defaults    1 2
>>
>>     jerry
>>
>>     --
>>
>>     -----------------------------------------------------------------------
>>     ----
>>     Jerold Lowry
>>     Principal Network/Systems Engineer
>>     Engineering Design Team (EDT), Inc. a HEICO company
>>     3423 NW John Olsen Pl
>>     Hillsboro, Oregon 97124 (U.S.A.)
>>     Phone: 503-690-1234 / 800-435-4320
>>     Fax: 503-690-1243
>>     Web: [4]https://url.emailprotection.link/?a4pOREhk_4MCW0PtjXkm2I74KsEDNqUHU1TlAGkvY7v8~
>>
>> References
>>
>>     1. mailto:systemd-cryptsetup@-dev-mapper-testcui.service
>>     2. https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~
>>     3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service
>>     4. https://url.emailprotection.link/?arGCBlB4ktQEllVdqrdFEHWz7tmQKHcDNQMQoUiVtXzs~
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> https://url.emailprotection.link/?ayE0YSl-8fsjTFuwcayuImPwuXvHCc0cXGaaipszDZOnBozAr3C_ngpEWBBTBT_i-8IP1XBKBwokSgi0QxfTytA~~
>


[-- Attachment #2: Type: text/html, Size: 7289 bytes --]

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Michael Kjörling]

On 20 Sep 2017 15:38 -0700, from jlowry@edt.com (Jerry Lowry):
> I have created an encrypted drive using the following commands:
> 
> #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file
> create /dev/mapper/testcui /dev/sdb

If that's what you _really_ did, I'm pretty sure it can't have worked.
The newline notwithstanding, whitespace still matters, and there is no
--verify parameter (you probably meant to use --verify-passphrase).


> Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for
> /dev/mapper/testcui...
> -- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has
> begun start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

At a minimum, run cryptsetup directly (not through systemd) with the
--debug flag and post back with the output thus obtained.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Ondrej Kozina]

On 09/21/2017 12:59 AM, Jerry Lowry wrote:
> Well, I have traced the error down to cryptsetup.c, line 564. Which is 
> getting a return code of less than 0 from crypt_activate_by_keyfile_offset.

That's systemd's own cryptsetup utility you're talking about I assume.

...anyway can you reproduce the issue using cmd line utility (genuine 
cryptsetup :)) run with --debug and --key-file options?

Regards
Ondrej

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Jerry Lowry]

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

If that's what you _really_ did, I'm pretty sure it can't have worked.
The newline notwithstanding, whitespace still matters, and there is no
--verify parameter (you probably meant to use --verify-passphrase).

Yes, I did you verify-passphrase, just a typo!

So, from the replies that I have gotten it sounds like there are two 
different camp ( groups) that are doing something with cryptsetup. Isn't 
that a duplication of effort?

---------------------------------------------------------------------------
Jerold Lowry
Principal Network/Systems Engineer
Engineering Design Team (EDT), Inc. a HEICO company
3423 NW John Olsen Pl
Hillsboro, Oregon 97124 (U.S.A.)
Phone: 503-690-1234 / 800-435-4320
Fax: 503-690-1243
Web: _www.edt.com <http://www.edt.com/>_


On 9/21/2017 12:25 AM, Michael Kjörling wrote:
> On 20 Sep 2017 15:38 -0700, from jlowry@edt.com (Jerry Lowry):
>> I have created an encrypted drive using the following commands:
>>
>> #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file
>> create /dev/mapper/testcui /dev/sdb
> If that's what you _really_ did, I'm pretty sure it can't have worked.
> The newline notwithstanding, whitespace still matters, and there is no
> --verify parameter (you probably meant to use --verify-passphrase).
>
>
>> Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for
>> /dev/mapper/testcui...
>> -- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has
>> begun start-up
>> -- Defined-By: systemd
>> -- Support: https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~
> At a minimum, run cryptsetup directly (not through systemd) with the
> --debug flag and post back with the output thus obtained.
>


[-- Attachment #2: Type: text/html, Size: 3402 bytes --]

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Arno Wagner]

You would think that. Unfortunately, the systemd people
are trying to replace a lot of things that worked well before,
not just cryptsetup. My guess would be this is an attempt at 
embrace-extend-extinguish and I can only recommend to avoid 
systemd altogether.

This group here is the original group for cryptsetup, the 
systemd version is an, apparently badly made, clone.

Regards,
Arno



On Thu, Sep 21, 2017 at 18:28:34 CEST, Jerry Lowry wrote:
> If that's what you _really_ did, I'm pretty sure it can't have worked.
> The newline notwithstanding, whitespace still matters, and there is no
> --verify parameter (you probably meant to use --verify-passphrase).
> 
>    Yes, I did you verify-passphrase, just a typo!
>    So, from the replies that I have gotten it sounds like there are two
>    different camp ( groups) that are doing something with cryptsetup.
>    Isn't that a duplication of effort?
> 
>    -----------------------------------------------------------------------
>    ----
>    Jerold Lowry
>    Principal Network/Systems Engineer
>    Engineering Design Team (EDT), Inc. a HEICO company
>    3423 NW John Olsen Pl
>    Hillsboro, Oregon 97124 (U.S.A.)
>    Phone: 503-690-1234 / 800-435-4320
>    Fax: 503-690-1243
>    Web: [1]www.edt.com
> 
> 
>    On 9/21/2017 12:25 AM, Michael Kjörling wrote:
> 
> On 20 Sep 2017 15:38 -0700, from [2]jlowry@edt.com (Jerry Lowry):
> 
> I have created an encrypted drive using the following commands:
> 
> #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file
> create /dev/mapper/testcui /dev/sdb
> 
> If that's what you _really_ did, I'm pretty sure it can't have worked.
> The newline notwithstanding, whitespace still matters, and there is no
> --verify parameter (you probably meant to use --verify-passphrase).
> 
> 
> 
> Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for
> /dev/mapper/testcui...
> -- Subject: Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has
> begun start-up
> -- Defined-By: systemd
> -- Support: [4]https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4
> ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~
> 
> At a minimum, run cryptsetup directly (not through systemd) with the
> --debug flag and post back with the output thus obtained.
> 
> References
> 
>    1. http://www.edt.com/
>    2. mailto:jlowry@edt.com
>    3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service
>    4. https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] problems mounting encrypted drive on reboot

[Milan Broz]

On 09/21/2017 06:28 PM, Jerry Lowry wrote:
> If that's what you _really_ did, I'm pretty sure it can't have worked.
> The newline notwithstanding, whitespace still matters, and there is no
> --verify parameter (you probably meant to use --verify-passphrase).
> 
> Yes, I did you verify-passphrase, just a typo!
> 
> So, from the replies that I have gotten it sounds like there are two different camp ( groups) that are doing something with cryptsetup.  Isn't that a duplication of effort?

Ok, because you tried to hijack other thread and reply out of list privately, I'll try to explain it here:

The systemd-cryptsetup uses libcryptsetup to activate devices.
So the cryptsetup code is there only once, but systemd decides to "own" and parse
/etc/crypttab with own tool - that's OK, crypttab was always owned by init and not by cryptsetup.

For your journald log:
I am not sure what the invalid parameter means, it could be bug but without additional debug
log we cannot say. (systemd should enable better log, it is easy)

Anyway, my guess is that you used keyfile in plain mode - then it is used directly as a key, hash
parameter does not apply. If there is not enough data for key, it must fail.

If you are configuring it with cryptsetup directly, you definitely should see this warning:
WARNING: The --hash parameter is being ignored in plain mode with keyfile specified.
(Or you have pretty old cryptsetup.)

Anyway, if you cannot use LUKS (you should because it solves exactly these issues) then
1) generate keyfile form /dev/urandom, be sure it is at least of the size of encryption key (usually 32 bytes).
   (dd if=/dev/urandom of=/dir/file bs=1 count=32)
2) use this as keyfile, do not specify hash: cryptsetup --key-file=/dir/file create testcui /dev/sdb
3) then use the same keyfile in crypttab. it should work.

m.