Przekonałem się, że działało, sudo bash
a następnie działało ecryptfs-recover-private
jako root (zamiast przez sudo). Nie jestem pewien, dlaczego powinno być inaczej.
Edytować:
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
Nie zobaczysz monitu i musisz wpisać swoje hasło do logowania, w ciemno, w powyższym poleceniu.
Zamień aaaaaaaaaaaaaaaa
i bbbbbbbbbbbbbbbb
poniżej podpisami szesnastkowymi między nawiasami z powyższego wyjścia, w kolejności:
# 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
Czynności wstępne
Okazuje się, że po prostu działa, ponieważ root nie działał dla mnie niezawodnie; czasami tak było, czasem nie. Zasadniczo ecryptfs wydaje się błędny i dość nieprzyjazny dla użytkownika, często mylący hasła logowania i hasła montowania. Po zejściu do głębokiej, ciemnej nory królika mam kilka wskazówek, które powinny pomóc. Te uwagi dotyczą Ubuntu 17.10, ecryptfs-utils 111-0 i powinieneś zostać rootem przed uruchomieniem. Zakładam, że chcesz zamontować swój katalog domowy z /mnt/crypt
(który powinien być już zamontowany) do /mnt/plain
, i powinieneś zastąpić user
nazwą użytkownika.
Zacznij łatwo
Pierwszą rzeczą do wypróbowania jest:
# ecryptfs-recover-private /mnt/crypt/.ecryptfs/user/.Private
Jeśli to zadziała, to masz szczęście. Jeśli nie, może pojawić się komunikat o błędzie z mount
około no such file or directory
. Jest to bardzo mylące: to, co tak naprawdę oznacza, to że twoje hasło montowania jest błędne lub go brakuje.
Zdobądź podpisy
Oto ważna część: musimy sprawdzić, czy ecryptfs naprawdę próbuje właściwych haseł montowania. Hasła muszą zostać załadowane do jądra Linuksa, zanim ecryptfs będzie mógł zamontować system plików. ecryptfs prosi jądro o ich podpis. Podpis jest 16-bajtową wartością szesnastkową (i nie jest wrażliwy na kryptografię). Możesz znaleźć sygnatury hasła, których oczekuje ecryptfs:
# cat /mnt/crypt/.ecryptfs/user/.ecryptfs/Private.sig
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb
Zapamiętaj to. Celem jest pobranie haseł z tymi sygnaturami załadowanymi do jądra, a następnie poinformowanie ecryptfs o ich użyciu. Pierwszy podpis ( aaaaaaaaaaaaaaaa
) dotyczy danych, a drugi ( bbbbbbbbbbbbbbbb
) to klucz szyfrowania nazwy pliku (FNEK).
Uzyskaj hasło montowania
To polecenie poprosi o podanie hasła logowania (z wprowadzającym w błąd pytaniem ) i wyświetli hasło montowania :
# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase
Skopiuj to, ale bądź ostrożny !! , ponieważ jest to niezwykle wrażliwa kryptograficznie, klucze do królestwa.
Wypróbuj interaktywne mocowanie
Następną rzeczą do wypróbowania jest:
# mount -t ecryptfs /mnt/crypt/.ecryptfs/user/.Private /mnt/plain
Kluczową rzeczą jest to, że mount
potrzebuje twojego (bardzo wrażliwego) hasła montowania , które właśnie skopiowaliśmy (nie twojego hasła logowania).
To zadaje ci kilka pytań i możesz zaakceptować wartości domyślne, z wyjątkiem powiedzenia „tak” Enable filename encryption
. Może dać ostrzeżenie i poprosić o buforowanie podpisów; możesz powiedzieć tak obu, ale sprawdź dokładnie, czy masz odpowiednie hasło montowania.
Zobaczysz opcje, które mount
zdecydowały się wypróbować dla Ciebie:
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
Jeśli podpisy są błędne (nie pasują do tego, co otrzymałeś Private.sig
), mount nie będzie działać.
... ale bardzo niepomyślnie zgłosi to. Będziesz musiał zrobić ls /mnt/plain
i cat plik, aby się upewnić. W tym momencie możesz również sprawdzić /var/log/syslog
i sprawdzić, czy ecryptfs szuka tych samych podpisów, co my.
Są wyraźnie dwa poważne problemy z ecryptfami i musimy je obejść.
Załaduj klucze do jądra
Jeśli interaktywne montowanie nie pomogło, musimy sami załadować klucze do jądra i ręcznie określić je w opcjach montowania.
# ecryptfs-add-passphrase --fnek
I wklej swoje (supersensowne) hasło montowane skopiowane z góry. To powinno wygenerować:
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring
Zamontuj ręcznie
Teraz hasła są ładowane do jądra i musimy tylko powiedzieć mountowi, aby ich używał:
# 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
Zauważysz, że opcje są podobne do wydrukowanych przez interaktywne mocowanie, z tym wyjątkiem, że ręcznie informujemy ecryptfs, co jest grane.
Mam nadzieję, że to działa. Jeśli nie, możesz sprawdzić, czy klucze są załadowane do jądra przy użyciu prawidłowych podpisów keyctl list @u
, które powinny wydrukować co najmniej dwa oczekiwane podpisy.
ecryptfs-recover-private
wyjście błędu montowania (2). spróbuj uruchomićsudo ecryptfs-manager
, naciśnij 4 (wyjście), a następnie uruchom ponownie oryginałecryptfs-recover-private
. powinien działać terazecryptfs
niektórych wersjach, a wywoływanie menedżera po prostu ustawia zmienne, które później są ponownie używane przez mounta. jakiś pomysł, jak to zautomatyzować, aby móc montować moje foldery po każdym ponownym uruchomieniu?keyctl link @u @s
było dla mnie bardzo prostym rozwiązaniem. Kredyty są dostępne tutaj: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126Dla przyszłych widzów tego pytania i odpowiedzi: ten sam widoczny objaw może być spowodowany różnymi podstawowymi przyczynami. Objaw wygląda następująco:
W moim przypadku ta odpowiedź była kluczem do rozwiązania. Problem polegał na tym, że próbowałem zrobić wszystko zdalnie przez SSH w sesji Tmux, co było ograniczone przez następujący wiersz
/etc/pam.d/sshd
:Wspomniana odpowiedź sugeruje skomentowanie tej linii i ponowienie próby w nowej sesji.
Prostym obejściem, które zadziałało w moim przypadku, było zrobienie tego na miejscu, całkowicie unikając SSH i Tmux. Bardziej skomplikowanym obejściem (którego nie zweryfikowałem) jest użycie czegoś takiego jak spisek, aby uzyskać zdalny dostęp do nieograniczonej liczby terminali.
źródło