Использование Ubuntu 18.04 после обновления с 16.04. На данный момент нет намерения обновляться до 20.04.
У меня возникают проблемы с ecryptfs при входе в систему одного из двух пользователей. Я работаю с tty-терминала, опасаясь, что автоматические операции графического интерфейса могут все усложнить.
Возможная причина этих проблем: я получил два набора подписей, которые обрабатывают один и тот же зашифрованный каталог.
Примечание по редактированию для первых читателей: разделы содержат изменения после самостоятельного устранения ошибки монтирования. Суть раздела 4 остается прежней. История короче.
После входа в систему я иногда получаю сообщение о том, что подпись 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]
В приглашении ecryptfs-unwrap-passphrase
выводится та же фраза-пароль, которая была у меня с тех пор, как я создал профиль пользователя ( много лет назад).
Это связано с двумя подписями (стандартной и типа FNEK), как говорит ecryptfs-add-passphrase --fnek
: они регулярно записываются в /home/.ecryptfs/user/.ecryptfs/ Private.sig
и, собственно, также в keyctl show
.
Проверяю 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)
Я считаю эту строку ОК: она соответствует настройкам другого пользователя на компьютере, для которых вход в систему и расшифровка все еще идут хорошо.
Вместо того, чтобы показать расшифрованный каталог, 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]
Эта ЕЩЕ ОДНА ПОДПИСЬ
является совсем другой подписью, чем те, что были разрешены выше.
Я тоже точно знаю, что это такое. ЕЩЕ ОДНА ПОДПИСЬ
— это стандартная подпись, создаваемая при вводе пароля для входа вместо пароля монтирования в ecryptfs-add-passphrase
или в некоторых других эквивалентных операциях, возможно, ecryptfs-recover-private
и ecryptfs-mount-private
.
Странно то, что я не могу найти никаких следов этого поддельного ключа в файлах внутри /home/.ecryptfs/user/.ecryptfs
и /root/.ecryptfs
. . Не знаю, откуда ecryptfs его берет.
Вчера мне удалось успешно применить ту же процедуру в живой среде USB (с обычными клавишами). Сегодня мне не удалось повторить этот успех в той же живой среде USB. Следовательно, должно было произойти что-то довольно разрушительное, что совершенно ускользнуло от меня.
Конечно, я повозился.Тем не менее, я исключаю запуск резкой команды типа «пожалуйста, перешифруйте все с новой парой ключей», в том числе потому, что инструмент менеджер ecryptfs
обескураживающе неудобен для пользователя.
Скорее всего, я ввел пароль для входа вместо пароля для монтирования где-то. По сути, я попал в пресловутую ловушку ecryptfs паролей входа/монтирования. Это две разные вещи, и ecryptfs едва удосуживается упомянуть, что именно она хочет. См. ecryptfs и фразу-пароль для входа и фразу-пароль для монтирования.