☰

Ecryptfs 找不到与挂载密码不关联的密钥

tag-icon • tag-icon 18.04 upgrade mount ecryptfs
Ecryptfs 找不到与挂载密码不关联的密钥

从 16.04 升级后使用 Ubuntu 18.04。目前没有打算升级到 20.04。

我在登录两个用户之一时遇到了 ecryptfs 问题。我正在使用tty 终端担心 GUI 的自动操作会使事情变得复杂。
这些问题的可能原因如下：我最终两组签名处理相同的加密目录。

给早期读者的编辑说明：一旦独立解决了安装错误，这些部分将发生更改。第 4 节的要点保持不变。故事更短。

1. 登录时的初始情况（已编辑）

登录后，我有时会收到 FNEK 签名不可用的消息。

[  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. 检查密码和密钥（已编辑）：通过

在提示符下ecryptfs-unwrap-passphrase输出相同的挂载密码自从我创建用户配置文件以来（几年前），我就一直拥有它。
这与两个签名（标准和 FNEK 类型）相关联，正如ecryptfs-add-passphrase --fnek所说：这些签名定期记录在案/home/.ecryptfs/user/.ecryptfs/Private.sig，事实上，还在keyctl show。

3. 加密目录挂载（已编辑）：通过

我仔细检查mount，发现这一行：

/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)

我认为这行没有问题：它对应于计算机中另一个用户的设置，该用户的登录和解密仍然顺利进行。

4. 惊喜：没有找到一个额外的密钥/签名

不显示解密的目录，而是ls /home/user生成此错误消息（实际上是的尾部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]

这ONE MORE SIGNATURE是完全是另一个签名比上面允许安装的那些要多。

我也确切地知道它是什么。ONE MORE SIGNATURE当我输入我的登录密码而不是挂载密码在ecryptfs-add-passphrase或在某些其他等效操作中，也许ecryptfs-recover-private也是ecryptfs-mount-private如此。

5. 分析

  • 奇怪的是，我无法在/home/.ecryptfs/user/.ecryptfs和里面的文件中发现这个伪密钥的任何踪迹/root/.ecryptfs。不知道 ecryptfs 从哪里得到它。

  • 昨天我确实成功地在 USB 实时环境中应用了同样的程序（使用普通键）。今天我没能在同一个 USB 实时环境中复制这一成功。因此，一定发生了一些相当混乱的事情，而我完全没有意识到。

  • 我确实瞎折腾了一番。不过，我排除了发出“请使用新密钥对重新加密所有内容”之类的极端命令的可能性，因为该工具的ecryptfs manager用户友好度令人沮丧。

  • 最有可能的是，我输入的是登录密码而不是挂载密码某处。基本上，我陷入了 ecryptfs 臭名昭著的登录/挂载密码陷阱。它们是两个不同的东西，ecryptfs 几乎不提它想要哪一个。参见ecryptfs 和登录密码与挂载密码。

6. 问题

  • 您如何解释这个再加一把钥匙的请求？
  • 有什么线索可以说明这把多余的钥匙是如何潜入的吗？
  • 任何建议如何解决它，恢复并安装原始密钥并解密目录？

7. 资料来源

答案1

上述分析中似乎可以肯定的一个事实是，调查过程中发生了失误或错误在某一天。用户配置文件/home/user当天没有以普通方式使用；因此没有新数据丢失。所有这些操作都是在 tty 终端中完成的。

由于 ecryptfs 加密单个文件、目录和链接 (inodes)，因此错误很可能是因为当天接触的某些 inode 使用错误的密钥对加密。即：对应于在某个时间某处输入登录密码（用户登录密码）而不是挂载密码（32 个字符的字符串）。

.Private因此，我将当天修改过的目录内的加密文件移到了其他地方（ls -tl | head -n 10对我有用）。

我退出并再次登录，然后收到一条消息

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

keyctl show确认系统不知道这些签名。'ecryptfs-mount-private' 修复了这个问题，我可以在命令行上看到解密的内容。第二次登录时，加密签名在密钥环中，我立即看到了目录。
（后期添加。我还注意到我可以忽略该消息：我输入ls后立即看到解密的内容。）

现在我可以一次恢复一个存储的 inode，只保留那些造成问题的 inode。其中一些 inode 可能是包含早于发生问题那天的文件的目录；你肯定不想丢失这些文件。我只会丢失一些文件。

基本上，如果您弄错了登录和挂载密码之间的区别（维护不善），ecryptfs 就不是万无一失的。一个错误可能会造成严重损害。只有几个文件的加密出现错误，这破坏了整个登录过程。

相关内容