Я обнаружил, что работает, sudo bashа затем работает ecryptfs-recover-privateот имени пользователя root (а не через sudo). Не уверен, почему это должно быть иначе.
Редактировать:
TL; DR:
# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase - | ecryptfs-add-passphrase --fnek -
< Type your login password here >
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring
Вы не увидите подсказку и должны ввести свой пароль для входа в систему вслепую в приведенной выше команде.
Замените aaaaaaaaaaaaaaaaи bbbbbbbbbbbbbbbbниже шестнадцатеричными сигнатурами в скобках от выходных данных выше, в следующем порядке:
# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain
прелиминарии
Оказывается, просто запуск от имени root не работал для меня надежно; иногда это так, иногда нет. По сути, ecryptfs кажется глючной и довольно недружественной для пользователя, часто путая пароли для входа в систему и парольные фразы монтирования. После того, как я спустился в глубокую темную кроличью нору, у меня есть несколько советов, которые должны помочь. Эти заметки относятся к Ubuntu 17.10, ecryptfs-utils 111-0, и вы должны стать пользователем root перед запуском. Я предполагаю, что вы хотите смонтировать ваш домашний каталог из /mnt/crypt(который должен быть уже смонтирован) в /mnt/plain, и вы должны заменить userимя пользователя.
Начните легко
Первое, что нужно попробовать:
# ecryptfs-recover-private /mnt/crypt/.ecryptfs/user/.Private
Если это работает, то вам повезло. Если нет, то может выдать сообщение mountоб ошибке от no such file or directory. Это вводит в заблуждение: на самом деле это означает, что ваша пароль для монтирования неверен или отсутствует.
Получить подписи
Вот важная часть: нам нужно убедиться, что ecryptfs действительно пытается ввести правильную парольную фразу (ы) монтирования. Парольные фразы должны быть загружены в ядро Linux, прежде чем ecryptfs сможет смонтировать вашу файловую систему. ecryptfs запрашивает их у ядра по их подписи. Подпись является 16-байтовым шестнадцатеричным значением (и не является криптографически чувствительным). Вы можете найти парольную фразу, которую ожидает ecryptfs:
# cat /mnt/crypt/.ecryptfs/user/.ecryptfs/Private.sig
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb
Помни это. Цель состоит в том, чтобы получить пароли с этими сигнатурами, загруженные в ядро, а затем указать ecryptfs для их использования. Первая сигнатура ( aaaaaaaaaaaaaaaa) предназначена для данных, а вторая ( bbbbbbbbbbbbbbbb) - это ключ шифрования FileName (FNEK).
Получить пароль для монтирования
Эта команда запросит у вас пароль для входа (с вводящей в заблуждение подсказкой) и выведет вашу пароль для монтирования :
# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase
Скопируйте это, но будьте осторожны! , поскольку это чрезвычайно криптографически чувствительно, ключи от королевства.
Попробуйте интерактивное крепление
Следующее, что нужно попробовать:
# mount -t ecryptfs /mnt/crypt/.ecryptfs/user/.Private /mnt/plain
Здесь важно, чтобы вам mountпонадобилась ваша (сверхчувствительная) пароль для монтирования, который мы только что скопировали (а не ваш пароль для входа).
Это задаст вам несколько вопросов, и вы можете принять значения по умолчанию, кроме как сказать «да» Enable filename encryption. Он может дать вам предупреждение и попросить кэшировать подписи; Вы можете сказать «да» обоим, но дважды проверьте, что у вас есть правильная пароль для монтирования.
Вы увидите варианты, которые mountрешил попробовать для вас:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=aaaaaaaaaaaaaaaa
Mounted eCryptfs
Если подписи неверны (не совпадают с тем, что вы получили Private.sig), монтирование не будет работать.
... но он очень бесполезно сообщит, что сделал. Вы должны сделать ls /mnt/plainи кошка файл, чтобы убедиться. На этом этапе вы также можете посмотреть /var/log/syslogи убедиться, что ecryptfs ищет те же подписи, что и мы.
Здесь явно есть две серьезные проблемы с ecryptfs, и мы должны их обойти.
Загрузите ключи в ядро
Если интерактивное монтирование не помогло, мы должны сами загрузить ключи в ядро и вручную указать их в опциях монтирования.
# ecryptfs-add-passphrase --fnek
И вставьте в свою (сверхчувствительную) маунт-фразу пароль, скопированный сверху. Это должно вывести:
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring
Монтировать вручную
Теперь парольные фразы загружаются в ядро, и нам просто нужно указать mount, чтобы использовать их:
# umount /mnt/plain
# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain
Вы заметите, что параметры похожи на то, что печатало интерактивное монтирование, за исключением того, что мы вручную сообщаем ecryptfs, что случилось.
Надеюсь, это работает. Если нет, вы можете проверить, что ключи загружены в ядро с использованием правильных подписей keyctl list @u, которые должны распечатать как минимум две подписи, которые вы ожидаете.
ecryptfs-recover-privateвыводит ошибку mount (2). попробуйте запуститьsudo ecryptfs-manager, нажмите 4 (выход), затем снова запустите оригиналecryptfs-recover-private. должен работать сейчасecryptfsнекоторой версии есть ошибка, и при вызове менеджера просто устанавливаются некоторые переменные, которые впоследствии повторно используются в mount.any, как автоматизировать это, чтобы я мог монтировать свои папки после каждой перезагрузки?keyctl link @u @sбыло очень простым решением для меня. Кредиты идут сюда: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126Для будущих зрителей этого Q & A: один и тот же очевидный симптом может быть вызван различными причинами. Симптом выглядит так:
В моем случае этот ответ содержал ключ к решению. Проблема заключалась в том, что я пытался сделать все удаленно через SSH в сеансе Tmux, который был ограничен следующей строкой
/etc/pam.d/sshd:Вышеупомянутый ответ предлагает прокомментировать эту строку и повторить попытку в новой сессии.
Простой обходной путь, который работал в моем случае, состоял в том, чтобы сделать это на месте, избегая SSH и Tmux в целом. Более сложный обходной путь (который я не проверял) заключается в использовании чего-то вроде conspy для удаленного доступа к неограниченному терминалу.
источник