Folosind Ubuntu 18.04 după o actualizare de la 16.04. Nicio intenție pentru moment de a face upgrade la 20.04.
Am probleme cu ecryptfs când mă conectez la unul dintre cei doi utilizatori. Lucrez de la a terminalul tty de teamă că operațiunile automate ale GUI pot complica lucrurile.
Există o cauză probabilă pentru aceste necazuri: am ajuns cu două seturi de semnături care gestionează același director criptat.
Notă de editare pentru cititorii timpurii: secțiunile conțin modificări, odată ce o eroare de montare a fost rezolvată independent. Esenta secțiunii 4 rămâne aceeași. Povestea este mai scurtă.
1. Situația inițială la conectare (editată)
După ce mă conectez, primesc uneori mesajul că semnătura FNEK nu este disponibilă.
[ 768.391515] Nu s-a putut găsi cheia cu descrierea: [semnătura fnek]
[ 768.392001] process_request_key_err: Nicio cheie
[ 768.392001] Nu s-a putut găsi cheia validă în sesiunea de chei utilizator pentru semnul specificat în opțiunea de montare: [semnătura fnek]
2. Verificarea expresiei de acces și a cheilor (editată): trece
La prompt ecryptfs-unwrap-passphrase iesiri la fel montați fraza de acces Am avut de când am creat profilul de utilizator (cu ani în urmă).
Aceasta este asociată cu cele două semnături (standard și de tip FNEK) ca ecryptfs-add-passphrase --fnek spune: acestea sunt înregistrate în mod regulat în /home/.ecryptfs/user/.ecryptfs/Private.sig și, de fapt, de asemenea în arată keyctl.
3. Montarea directorului criptat (editat): trece
Verific din nou montură și găsiți linia:
/home/.ecryptfs/user/.Privat pe /home/user tip ecryptfs(rw,nosuid,nodev,relatime,
ecryptfs_fnek_sig=**semnătura fnek**,
ecryptfs_sig=**semnătura standard**,
ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
Consider această linie OK: corespunde setărilor pentru celălalt utilizator din computer, pentru care încă merge bine autentificarea și decriptarea.
4. Surpriză: o cheie/semnătură suplimentară nu a fost găsită
În loc să arate directorul decriptat, ls /home/user produce acest mesaj de eroare (de fapt, coada lui dmesg):
[ 3068.228947] Nu s-a putut găsi cheia cu descrierea: [ÎNCĂ O SEMNATURĂ]
[ 3068.228948] process_request_key_err: Nicio cheie
[ 3068.228948] ecryptfs_parse_tag_70_packet: Eroare la încercarea de a găsi codul de autentificare pentru fnek sig [ÎNCĂ O SEMNATURĂ]; rc = [-2]
Acest INCA O SEMNATURA este cu totul altă semnătură decât cele deasupra cărora permiteau montarea.
De asemenea, știu exact ce este. INCA O SEMNATURA este semnătura standard produsă atunci când scriu my Parola de logare in loc de montează parola în ecryptfs-add-passphrase sau într-o altă operațiune echivalentă, poate ecryptfs-recover-private și ecryptfs-mount-private de asemenea.
5. Analiză
Lucrul ciudat este că nu pot găsi nicio urmă a acestei chei false în fișierele din interior /home/.ecryptfs/user/.ecryptfs și /root/.ecryptfs. Nicio idee despre unde îl ia ecryptfs.
Ieri am reușit să aplic cu succes aceeași procedură într-un mediu USB live (cu tastele normale).
Astăzi nu am reușit să reproduc acel succes în același mediu USB live.
Prin urmare, trebuie să se fi întâmplat ceva destul de perturbator, care mi-a scăpat complet.
Cu siguranță m-am jucat. Cu toate acestea, exclud să fi lansat o comandă drastică de genul „vă rog să recriptați totul cu o nouă pereche de chei”, și pentru că instrumentul managerul ecryptfs este descurajator de neprietenos pentru utilizator.
Cel mai probabil, am tastat o expresie de acces de conectare în loc de o expresie de acces de montare undeva. Practic, am căzut în capcana notorie a ecryptfs a parolelor de conectare/montare. Sunt două lucruri diferite, iar ecryptfs abia se deranjează să menționeze ce vrea. Vedea ecryptfs și expresie de acces de conectare vs.
6. Întrebări
- Cum interpretați această solicitare a încă o cheie?
- Aveți vreo idee despre cum s-ar fi putut strecura această cheie suplimentară?
- Orice sugestie despre cum să-l scoți din drum, reveniți și solicitați cheile originale să monteze și să decripteze directorul?
7. Surse
