A related question would be: luksOpen doesn't decrypt with keyfile unless --key-file argument is provided

On Ubuntu bionic with cryptsetup 2.0.2 however, I do encounter the following problem:

when opening a luks encrypted device by using a password contained in a file it works well on the direct call:

cat mypass.txt | sudo cryptsetup open --type luks /dev/sda1 enc-store

trying to use the documented --key-file=- argument, which should result in the same behavior

cat mypass.txt | sudo cryptsetup open --type luks --key-file=- /dev/sda1 enc-store

just producing the delayed message

No key available with this passphrase.

this is especially a problem, when trying to use the script cryptdisks_start enc-store, which relies on the --key-file=- option, which produces the above message thrice

which makes life a tad less enjoyable.

am I missing something here?


  • 1
    Did you think about not including the final LF (\n) in the file?
    – A.B
    Aug 22, 2018 at 9:43
  • I didn't expect vim to add a \n if there is no empty line at the end of the file
    – qbit
    Aug 22, 2018 at 11:29

1 Answer 1


There is a difference between the two commands, as described in man cryptsetup:

--key-file, -d name
Read the passphrase from file.

If the name given is "-", then the passphrase will be read from stdin. In this case, reading will not stop at newline characters.

That means if you generated your file using echo, vi, or copy/pasting, it most likely includes a newline at the end. if used as pure stdin (no --key-file option), it will have its final newline ignored, but when used as a parameter to --key-file, even if it's the same stdin (--key-file=- ) it will get this newline included in the passphrase: it becomes a new passphrase which is invalid.

To verify this:

cat mypass.txt | tr -d '\r\n' | sudo cryptsetup open --type luks --key-file=- /dev/sda1 enc-store

Should work as intended (just in case I remove any CR too).

Should that be the cause, just remove this newline: eg

mv -i mypass.txt mypass.old && tr -d '\r\n' < mypass.old > mypass.txt

What you should probably do anyway is to generate a new passphrase from pure random numbers, put it in a secure file, and include it in a separate LUKS slot.

  • and I thought, I had checked for that... thanks :)
    – qbit
    Aug 22, 2018 at 11:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .