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
3. Mount of encrypted directory (edited): pass
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
[ 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]
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
The odd thing is that I cannot find any trace of this spurious key in the files inside
/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 manageris 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.
- 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?
- Recovering a partition with encrypted /home directory in Ubuntu 18..04
- ecryptfs-recover-private mounts wrong filesystem
- problem with ecryptfs-recover-private: mount(2) failed