Does
cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key
work?

If not, your keyfile contains EOL (\n) and because keyfiles take EOL as normal char (while in interactive or pipe) input EOL causes end of input.

So in this case just trim your keyfile so it contain only chars before first \n - or change LUKS keyslot to use this keyfile. 
(Check with "hexdump -c /etc/crypttab.lin-bak.key".)

# umount /lin-bak

# cryptsetup remove /dev/mapper/lin-bak

# cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key
No key available with this passphrase.

# cryptsetup luksOpen /dev/sdb1 lin-bak < /etc/crypttab.lin-bak.key
<It worked>


And,
# hexdump -c /etc/crypttab.lin-bak.key
0000010 ...   \n

At this point, I have to cry foul!  "vi -b /etc/crypttab.lin-bak.key" shows this file to be a simple one line file.  If I add a second empty line, hexdump gives me two "\n" at the end of the file.  Since "vi" will not create a "\n" free file, how in the world am I to create a text file without a "\n" at the end?

And, more foul,
# hexdump -c < /etc/crypttab.lin-bak.key
0000010 ...   \n

Which does work, also has a "\n" in it!

I am really confused!

-T

More confusion, if I am not mistaken, if I find a way to remove the "\n", do I not get a 1024 character long file?

You can create it e.g.
echo -n "mypassword" >file

For removing \n... I would ether use dd (dd if=oldfile of=newfile bs=1 count=N-1) or something even more clever like... vi?

:set binary
:set noeol
(first hit on google btw ;-)

If you use it as keyfile (luksAddKey for example) then the \n will be just part of keyfile. 

So this is not bug, just quite problematic handling of \n in cryptsetup (which must be there for compatibility reasons...)

Hi Milan,

Maybe not a bug, but really bad programming.  Who in the world in going to know they have to create the keyfile without the "\n"?

This there any chance you can use your considerable influence to get this fixed?  If not, can you at least get something put into the man page on the "\n" free requirement and how to create a  "\n" free keyfile?

Many thanks,
-T

Hi Milan,

I rebooted with my rc.local work around commented out.  I am confirming that your fix works.  /lin-bak mounted properly from fstab.

Thinking about the problem: I do believe that crypttab is expected to accept lie feeds (\n) as a possible password, so this is why I had the problem.  That being the case, the \n feed requirement must be documented in the man page.  Otherwise it is going to drive a lot of folks nuts, especially since I googled my eyeballs out and found nothing before reporting to you.

Should I open a new bug on the man page or can you just use this one and change the name?

see man cryptsetup - NOTES ON PASSPHRASE PROCESSING FOR LUKS section

crypttab has parameter for keyfile, so it is processed like a keyfile.
(but I do not maintain crypttab processing...)

Btw Debian crypttab man page has this:

The third field, key file, describes the file to use as a key for decrypting the data of the source device. Note that the entire key file will be used as the passphase; the passphase must not be followed by a newline character.

No idea why it is not in Fedora/RHEL man page. Reopen this bug it you want to fix man crypttab page (it is part of initscritps package).

(...and eventually RHEL can do it even without "passphase/passphrase" typos :-)

(In reply to comment #9)
> (...and eventually RHEL can do it even without "passphase/passphrase" typos
> :-)

I went to publik skol!  :-)

How about my question about correcting the man page?  If you decide to do that, I will volunteer to write it.  (You can fix my spelling and cherry it out)

-T

Please move all activity on this bug to:

crypttab tab man page password section needs to be updated
https://bugzilla.redhat.com/show_bug.cgi?id=846140