problem z ecryptfs-recovery-private: nie powiodło się montowanie (2)

11

Jestem w trakcie przenoszenia mojego systemu operacyjnego i danych z jednego dysku na drugi na tym samym komputerze. (Mam ładny, nowy dysk SSD.) Mój stary katalog domowy zawierał zaszyfrowany podkatalog i chciałbym uzyskać dostęp do zaszyfrowanego katalogu z mojej nowej instalacji. Próbuję użyć ecryptfs-recover-private. Wystąpił jednak następujący błąd.

$ sudo ecryptfs-recover-private /BLAH/.Private
INFO: Found [.Private/].
Try to recover this directory? [Y/n]: 
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] 
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [BLAH] into the user session keyring
mount: mount(2) failed: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.NcWkVmQ5].

Napotykam ten sam problem, jeśli pozwalam ecryptfs-recover-privateznaleźć katalog samodzielnie lub jeśli odmawiam hasło logowania, ale zamiast tego używam hasła mount.

Myśli?

(Zdaję sobie sprawę, że na tej stronie jest kilka podobnych pytań, ale żadne z nich nie wydaje się w pełni obejmować mojej sytuacji).

lmmaurer
źródło

Odpowiedzi:

5

Więc to proste polecenie ecryptfs-recover-privateokazało się zawodne. Żadna z powyższych metod nie działała dla mnie, próbując przejść z ecryptfs do kontenera LUKS .

To, co zadziałało, to ręczna metoda opisana na wiki społeczności Ubuntu

Szczegółowo:

# sudo -i
# ecryptfs-add-passphrase --fnek 
Inserted auth tok with sig [aaaaaaaaaaaaa] into the user session keyring 
Inserted auth tok with sig [bbbbbbbbbbbbb] into the user session keyring  
# mkdir -p /mnt/new_mount_point  
# mount -t ecryptfs /mnt/old_mount_point/home/username/.Private /mnt/new_mount_point
  • wybierz 3 (użyj typu klucza hasła i użyj odzyskanego hasła, czyli unwrapped-passsphrase)
  • wybierz aes (użyj szyfru aes)
  • wybierz 16 (użyj 16-bajtowego klucza)
  • włącz przekazywanie tekstu jawnego: n
  • włącz szyfrowanie plików: y
przesilenie dnia z nocą
źródło
2
to zadziałało dla mnie, ale po szyfrowaniu nazwy pliku pojawia się ostatnie pytanie, które wymaga użycia podpisu FNEK, domyślnie do pierwszego tokena uwierzytelnienia w danych wyjściowych ecryptfs-add-passphrase --fnek. Stwierdziłem, że zamiast tego musiałem użyć drugiego.
darrend
To. Jedyną metodą, która działa dla mnie, jest otwarcie wiki społeczności Ubuntu, do której prowadzi link, i postępowanie zgodnie z instrukcjami.
fdierre
To zadziałało dla mnie! Postępowałem zgodnie z instrukcjami „Ręczne odzyskiwanie danych”, jak wskazałeś, tutaj: help.ubuntu.com/community/… . Pamiętaj tylko, że jeśli chcesz również postępować zgodnie z sekcją „Odzyskiwanie hasła do góry”, musisz użyć sudo, nawet jeśli o tym nie wspominają. tzn .: zamiast ecryptfs-unwrap-passphrase /home/username/.ecryptfs/wrapped-passphrase, do sudo ecryptfs-unwrap-passphrase /home/.ecryptfs/username/.ecryptfs/wrapped-passphrase(zauważ również nieco inną ścieżkę, której użyłem).
Gabriel Staples
To rozwiązanie wydaje się na dzień dzisiejszy niekompletne. Jest jeszcze jedno pytanie: Filename Encryption Key (FNEK) Signature [XYZ]:nie mam pojęcia, co to za podpis ... @ Rozwiązanie Martina ( askubuntu.com/a/679565/924202 ) zrobiło to dla mnie. :-)
breversa
5

Nie jestem pewien, dlaczego tak się dzieje - być może zepsucie breloka jądra podczas korzystania z tego samego hasła LOGIN w nowej konfiguracji, jak w tej, którą próbujesz odzyskać.

To powiedziawszy, dodanie zawiniętego hasła do pliku kluczy jądra przed próbą odzyskania systemu plików działa (pamiętaj, aby użyć sudoobu poleceń poniżej):

sudo ecryptfs-insert-wrapped-passphrase-into-keyring /BLAH/.ecryptfs/wrapped-passphrase
sudo ecryptfs-recover-private /BLAH/.Private
Jaskółka oknówka
źródło
Dzięki! To zadziałało dla mnie ...
Kanchu
sudojest wymagane również przy pierwszym poleceniu ( ecryptfs-insert-wrapped-passphrase-into-keyring), w przeciwnym razie pojawia się następujący błąd! Error: Unwrapping passphrase and inserting into the user session keyring failed [-5] Info: Check the system log for more information from libecryptfs
Gabriel Staples,
1
... ale niestety sudo ecryptfs-recover-private /BLAH/.Privatedla mnie drugie polecenie ( ) nadal nie działa. :(mount: /tmp/ecryptfs.aLkDeiWo: mount(2) system call failed: No such file or directory. ERROR: Failed to mount private data at [/tmp/ecryptfs.aLkDeiWo].
Gabriel Staples,
To również działało dla mnie. Najwyraźniej istnieje otwarty błąd od 2018 r. Z hacką poprawką, ale nadal nie został naprawiony: bugs.launchpad.net/ecryptfs/+bug/1769373
breversa
2

Obecnie używam testów Debiana i ostatnio potrzebowałem odzyskać plik z kopii zapasowej mojego zaszyfrowanego folderu .Private. Kopia zapasowa jest przechowywana na moim serwerze NAS. Wystąpił ten sam problem co ty. Ręczne wstawienie zapakowanego hasła nie pomogło i ręczne zamontowanie systemu plików cifs (z mojego NAS) przez rootowanie zamiast tworzenia montowania jako mój główny użytkownik (aby zapobiec właściwym konfliktom i tym podobne) również nie pomogło.

Jednak po zwykłym ponownym uruchomieniu systemu mogłem bezpośrednio użyć polecenia ecryptfs-recovery-private, aby zamontować folder .Private, który sam był umieszczony w systemie plików cifs.

Chociaż nie wyjaśnia to, co się dzieje źle, i jest to jedna z bardziej frustrujących wskazówek, które można uzyskać jako użytkownik systemu Linux:

uruchom ponownie system i spróbuj ponownie :)

Sven
źródło
Ach, najstarsza sztuczka w książce! Dobrze wiedzieć.
lnmaurer,
1

Miałem podobne błędy po zmianie nazwy poprzedniej (oryginalnej) nazwy użytkownika POSIX na old_user (i), a następnie utworzyłem nowego użytkownika o oryginalnej nazwie (poprzedniej nazwy użytkownika).

Aby móc zamontować zaszyfrowany katalog domowy ze starego użytkownika, musiałem przerobić dowiązania symbolik dla .encryptfs i .Private w jego folderze (tak jak to zrobili po / home / original_name /).

Następnie następujące polecenie zamontowało stary dom bez żadnego problemu. / usr / bin / ecryptfs-recovery-private /home/old_user/.Private

Jarosław Fedorina
źródło
Myślę, że mam bardzo podobny problem, ale nie jestem pewien, jak go rozwiązałeś ... Czy masz coś przeciwko spojrzeniu na mój nowy post? Dzięki! askubuntu.com/questions/1035424/…
Matifou
Cześć Matifou! Co masz w swoim dzienniku systemowym zaraz po próbie wykonania ecryptfs-recovery-private /home/.ecryptfs/old_user/.Private?
Jarosław Fedorina
Hej! Jeśli masz problemy z kluczem (patrz dmesg lub syslog), np. Nie można znaleźć klucza z opisem: [XXX] proces_wymagania_klucza: Brak klucza Nie można znaleźć prawidłowego klucza w kluczu sesji użytkownika dla sig określonego w opcji montowania: [XXX], spróbuj ręcznie dodać hasło: Opcja „1” w / usr / bin / ecryptfs-manager Pomogło mi to.
Jarosław Fedorina
0

Spędziłem godziny na tym problemie, nie rozumiejąc, dlaczego te proste polecenia nie działały. Znalazłem, że wprowadzają w błąd linki w ... / home / .ecryptfs i ... / home / .ecryptfs /username/.ecryptfs.

EDYCJA : należy potwierdzić następujące rozwiązanie. Ponowne połączenie może nie być obowiązkowe, ale podane parametryecryptfs-recover-private mogą być źródłem problemu.

Moim rozwiązaniem było ponowne połączenie ze ścieżką względną pliku .Private i .ecryptfs w /home/.ecryptfs/

Opracować:

W moim przypadku użytkownik domowy, którego chciałem przeczytać, był w katalogu / mnt / sda5 / home, a użytkownik był facetem

    $ cd /mnt/sda5/home 

    $ ls -lag .ecryptfs/guy/
        drwxr-xr-x  4 guy    4096  .
        drwxr-xr-x  3 root   4096  ..
        drwx------ 16 guy    4096  .Private
        drwx------  2 guy    4096  .ecryptfs


    $ ls -lag .ecryptfs/guy/.ecryptfs/
        drwx------ 2 guy 4096 Jan 1 00:12 .
        drwxr-xr-x 4 guy 4096 Jan 1 00:11 ..
        -rw------- 1 guy   13 Jan 1 00:11 Private.mnt
        -rw------- 1 guy   34 Jan 1 00:11 Private.sig
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-mount
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-umount
        -rw------- 1 guy   58 Jan 1 00:12 wrapped-passphrase

    #This were the data are stored

Jeśli umieścisz listę plików w katalogu domowym, masz następujące linki (przed moją korektą)

    $ ls -lag guy/
   lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private  -> /home/guy/.Private
   lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> /home/guy/.ecryptfs

więc pliki łączą się z bieżącym / home i użytkownikiem, a nie z tymi, które próbujesz odczytać, myląc ciebie i polecenia montowania.

Po korekcie zaimplementowałem:

    $ ls -lag guy/
    dr-x------ 2 guy 4096 Jan 2 15:52 .
    drwxr-xr-x 6 root   4096 Jan 1 00:11 ..
    lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private -> ../.ecryptfs/guy/.Private
    lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> ../.ecryptfs/guy/.ecryptfs
    lrwxrwxrwx 1 guy   56 Jan 1 00:11 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
    lrwxrwxrwx 1 guy   52 Jan 1 00:11 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

Moim rozwiązaniem było ponowne połączenie ze ścieżką względną pliku .Private i .ecryptfs

    $ cd /mnt/sda5/home 
    $ cd guy
    $ sudo unlink .Private
    $ sudo unlink .ecryptfs 
    $ sudo ln -sr ../.ecryptfs/guy/.Private
    $ sudo ln -sr ../.ecryptfs/guy/.ecryptfs

Po można ręcznie zamontować katalog domowy ręcznie lub za pomocą

 cd /mnt/sda5/home 
 sudo ecryptfs-recover-private .ecryptfs/guy/.ecryptfs/.Private

(będziesz potrzebować hasła MOUNT - seria 32 znaków)

kFly
źródło