Join Log in
Score:0
XavierStuvw avatar Ubuntu

Ecryptfs cannot find a key NOT associated with the mount passphrase

cn flag
XavierStuvw

Using Ubuntu 18.04 after an upgrade from 16.04. No intention for the moment to upgrade to 20.04.

I am having troubles with ecryptfs when logging in into one of two users. I am working from a tty terminal for fear that the automatic operations of the GUI can complicate things.
There is a probable cause for these troubles: I ended up with two sets of signatures that handle the same encrypted directory.

Editing note for early readers: the sections contain changes, once a mount error has been sorted out independently. The gist of section 4 remains the same. The story is shorter.

1. Initial situation at login (edited)

After I log in, I sometimes receive the message that the FNEK signature is not available.

[  768.391515] Could not find key with description: [the fnek signature]
[  768.392001] process_request_key_err: No key
[  768.392001] Could not find valid key in user session keyring for sig specified in mount option: [the fnek signature]

2. Check of the passphrase and keys (edited): pass

At the prompt ecryptfs-unwrap-passphrase outputs the same mount passphrase I have had ever since I created the user profile (years ago).
This is associated with the two signatures (standard and FNEK-type) as ecryptfs-add-passphrase --fnek says: these are regularly recorded in /home/.ecryptfs/user/.ecryptfs/Private.sig and, in fact, also in keyctl show.

3. Mount of encrypted directory (edited): pass

I double-check mount and find the line:

/home/.ecryptfs/user/.Private on /home/user type ecryptfs(rw,nosuid,nodev,relatime,
ecryptfs_fnek_sig=**the fnek signature**,
ecryptfs_sig=**the standard signature**,
ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

I consider this line OK: it corresponds to the settings for the another user in the computer, for which the login and decryption still go well.

4. Surprise: one extra key/signature is not found

Instead of showing the decrypted directory, ls /home/user produces this error message (actually the tail of dmesg):

[ 3068.228947] Could not find key with description: [ONE MORE SIGNATURE]
[ 3068.228948] process_request_key_err: No key
[ 3068.228948] ecryptfs_parse_tag_70_packet: Error attempting to find auth tok for fnek sig [ONE MORE SIGNATURE]; rc = [-2]

This ONE MORE SIGNATURE is altogether another signature than the ones above which permitted the mount.

I also know precisely what it is. ONE MORE SIGNATURE is the standard signature produced when I type my login password instead of the mount password in ecryptfs-add-passphrase or in some other equivalent operation, perhaps ecryptfs-recover-private and ecryptfs-mount-private too.

5. Analysis

  • The odd thing is that I cannot find any trace of this spurious key in the files inside /home/.ecryptfs/user/.ecryptfs and /root/.ecryptfs. No clue about where ecryptfs gets it from.

  • Yesterday I did manage to apply these same procedure in a USB live environment successfully (with the normal keys). Today I failed to replicate that success in the same USB live environment. Therefore, something fairly disruptive must have happened, which completely escaped me.

  • I certainly fiddled around. However, I rule out to have launched a drastic command like "please re-encrypt everything with a new key pair", also because the tool ecryptfs manager is discouragingly user-unfriendly.

  • Most likely, I typed a login passphrase instead of a mount passphrase somewhere. Basically, I fell in ecryptfs' notorious trap of the login/mount passwords. They are two different things, and ecryptfs barely bothers to mention which it wants. See ecryptfs and login passphrase vs mount passphrase.

6. Questions

  • How do you interpret this request of one more key?
  • Any clue of how this extra key could have crept in?
  • Any suggestion on how to get it out of the way, revert and have the original keys mount and decrypt the directory?

7. Sources

105
0 + 0
Score:0
XavierStuvw avatar Ubuntu
cn flag
XavierStuvw

A fact that appears to be certain in the analysis above is that a pas faux or mistake occurred during the investigations on a specific day. The user profile and /home/user had not been used in an ordinary fashion that day; so there is no new data to lose. All these operations have been done in a tty terminal.

Since ecryptfs encrypts individual files, directories and links (inodes), it is likely that the error arose because some inodes touched on that day have been encrypted with a wrong key pair. Namely: with that corresponding to having typed in somewhere some time a login passphrase (the user login password) instead of a mount passphrase (the 32-character string).

Therefore, I moved to elsewhere the encrypted files inside the .Private directory that had been modified on that day (ls -tl | head -n 10 worked for me).

I exited, logged in again and received a message

Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'

keyctl show confirms that the system has no notion of those signatures. 'ecryptfs-mount-private' fixes it and I can see the decrypted content on the command line. At the second login the encryption signatures are in the keyring and I see the directories immediately as it should.
(Late addition. I also noted that I can ignore that message: I type ls and see decrypted content straight away.)

Now I can restore one at time the inodes stored away and leave out only those that caused offence. Some of those inodes can be directories containing files older than the day in which things went wrong; and you don't want to lose those files. I will have lost only a few files.

Basically, ecryptfs is not fail safe if you get the (poorly maintained) distinction between login and mount passphrases wrong. An error can can cause critical damage. Only the encryption of a few files went wrong, and this spoiled the entire process of logging in.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.