mount: Немає такого файлу чи каталогу із зашифрованим відновленням


12

Я знищив установку Mint Linux. Я просто хотів отримати доступ до своєї віддаленої вітрини. Тож сталося, що у мене виникли проблеми з файлом ICEauthority в моєму домашньому каталозі. Отже, дотримуючись різних вказівок в Інтернеті, я прийшов до висновку, що я можу встановити домашній каталог рекурсивно на chmod 755, щоб цей файл працював… врешті-решт у мене виникли проблеми із завантаженням системи. Врешті-решт, встановивши домашній каталог на виконавчий дозвіл для root, я зміг отримати доступ для читання / запису… але потім я скинув свою машину, о, чому я, чому я скинув свою машину !!! - тепер система кидає мені ту саму помилку з ICEauthority, але вона ніколи не потрапляє мені в ОС, оскільки диск зашифрований. Ніщо, що я спробував, здається, не працює, і у мене немає оригінального монтажного насіння.

frankenmint@honeybadger /home $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

Я дуже переживаю, тому що у мене були важливі файли, які зберігалися на віртуальній машині… Якби я міг просто дістатися до цих файлів, я б не мав жодних труднощів, що знімають налаштування і починають спочатку

Відповіді:


13

Я виявив, що працює 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

Пам'ятайте про це. Мета - отримати парольні фрази з цими підписами, завантаженими в ядро, а потім сказати шифрам, щоб ними користуватися. Перший підпис ( 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-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, які повинні роздрукувати принаймні два підписи, які ви очікуєте.


4
є вирішення, коли ecryptfs-recover-privateвиводиться помилка mount (2). спробуйте запустити sudo ecryptfs-manager, натисніть 4 (вихід), а потім знову запустіть оригінал ecryptfs-recover-private. має працювати зараз
ulkas

1
@ulkas Будь-яка ідея, чому це працює?
Турін

2
@Turion я googled рішення, так що я не винахідник. я здогадуюсь, чи є помилка в ecryptfsдеякій версії і виклик менеджера просто встановлює деякі змінні, які пізніше повторно використовуються mount.any ідеєю, як це автоматизувати, щоб я міг змонтувати свої папки після кожного перезавантаження?
ulkas

1
keyctl link @u @sбуло для мене набагато простим рішенням. Кредити йдуть сюди: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126
sup

Хоча моя проблема, мабуть, відрізнялася від оригінального плаката.
суп

1

Для майбутніх глядачів цього запитання: той самий очевидний симптом може бути викликаний різними основними причинами. Симптом виглядає так:

INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

У моєму випадку ця відповідь була ключем до рішення. Проблема полягала в тому, що я намагався зробити все віддалено через SSH під час сеансу Tmux, який був обмежений наступним рядком у /etc/pam.d/sshd:

session    optional     pam_keyinit.so force revoke

Вищезгадана відповідь пропонує прокоментувати цю лінію та спробувати ще раз у новому сеансі.

Просте вирішення, яке працювало в моєму випадку, полягало в тому, щоб це зробити на місці, уникаючи SSH та Tmux взагалі. Більш складним способом (який я ще не перевірив) є використання чогось, як конспіра, щоб отримати доступ до необмеженого терміналу віддалено.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.