Использование Ubuntu 18.04 после обновления с 16.04. На данный момент нет намерения обновляться до 20.04.
У меня проблемы с ecryptfs при входе в систему одного из двух пользователей. я работаю из телетайп-терминал опасаясь, что автоматические операции графического интерфейса могут все усложнить.
Существует вероятная причина этих проблем: я закончил с два комплекта подписей которые обрабатывают один и тот же зашифрованный каталог.
Редактирование примечания для первых читателей: разделы содержат изменения, раз ошибка монтирования разобралась самостоятельно. Суть раздела 4 остается прежней. История короче.
1. Исходная ситуация при входе в систему (отредактировано)
После входа в систему я иногда получаю сообщение о том, что подпись FNEK недоступна.
[768.391515] Не удалось найти ключ с описанием: [подпись fnek]
[768.392001] process_request_key_err: Нет ключа
[768.392001] Не удалось найти действительный ключ в наборе ключей сеанса пользователя для sig, указанного в параметре монтирования: [подпись fnek]
2. Проверка парольной фразы и ключей (отредактировано): pass
В подсказке ecryptfs-развернуть-пароль выводит то же самое смонтировать парольную фразу У меня было с тех пор, как я создал профиль пользователя (много лет назад).
Это связано с двумя подписями (стандартной и типа ФНЭК), т.к. ecryptfs-добавить-пароль --fnek говорит: они регулярно записываются в /home/.ecryptfs/пользователь/.ecryptfs/Private.sig а на самом деле, также в keyctl показать.
3. Монтировать зашифрованный каталог (отредактировано): pass
я перепроверяю устанавливать и найти строку:
/home/.ecryptfs/user/.Private on /home/user type ecryptfs(rw,nosuid,nodev,relatime,
ecryptfs_fnek_sig=**подпись fnek**,
ecryptfs_sig=**стандартная подпись**,
ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
Я считаю эту строку исправной: она соответствует настройкам для другого пользователя на компьютере, у которого вход и расшифровка по-прежнему проходят нормально.
4. Сюрприз: один лишний ключ/подпись не найден
Вместо того, чтобы показывать расшифрованный каталог, лс /дом/пользователь выдает это сообщение об ошибке (фактически хвост dmesg):
[ 3068.228947] Не удалось найти ключ с описанием: [ЕЩЕ ОДНА ПОДПИСЬ]
[3068.228948] process_request_key_err: Нет ключа
[3068.228948] ecryptfs_parse_tag_70_packet: ошибка при попытке найти ток аутентификации для fnek sig [ЕЩЕ ОДНА ПОДПИСЬ]; rc = [-2]
Этот ЕЩЕ ОДНА ПОДПИСЬ является вообще другая подпись чем те, что выше, которые разрешали крепление.
Я тоже точно знаю, что это такое. ЕЩЕ ОДНА ПОДПИСЬ это стандартная подпись, создаваемая, когда я набираю логин Пароль вместо монтировать пароль в ecryptfs-добавить парольную фразу или в какой-либо другой эквивалентной операции, возможно ecryptfs-recover-private и ecryptfs-mount-private тоже.
5. Анализ
Странно то, что я не могу найти никаких следов этого ложного ключа в файлах внутри /home/.ecryptfs/пользователь/.ecryptfs и /корень/.ecryptfs. Не знаю, откуда ecryptfs его берет.
Вчера мне удалось успешно применить ту же процедуру в живой среде USB (с обычными клавишами).
Сегодня мне не удалось повторить этот успех в той же живой среде USB.
Следовательно, должно было произойти что-то довольно разрушительное, что совершенно ускользнуло от меня.
Я конечно возился. Тем не менее, я исключаю запуск резкой команды типа «пожалуйста, перешифруйте все с помощью новой пары ключей», в том числе потому, что инструмент менеджер ecryptfs обескураживающе неудобен для пользователя.
Скорее всего, я ввел пароль для входа в систему вместо пароля для монтирования. где-то. По сути, я попал в пресловутую ловушку ecryptfs паролей входа/монтирования. Это две разные вещи, и ecryptfs едва удосуживается упомянуть, что именно она хочет. Видеть ecryptfs и парольная фраза для входа и парольная фраза для монтирования.
6. Вопросы
- Как вы интерпретируете этот запрос еще одного ключа?
- Любая подсказка о том, как этот дополнительный ключ мог прокрасться?
- Любое предложение по как убрать это с дороги, вернуть исходные ключи и смонтировать и расшифровать каталог?
7. Источники
