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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.