adatvesztés

 ( skylooker | 2018. március 20., kedd - 22:49 )

Segítséget kérek a következő témában: Ultimate Linux nem enged belépni, nem ismeri fel a jelszót.
A home könyvtárat live-cd-ről sem érem el, titkosított. Az ott levő adatokat nem tudom elérni/lementeni.
(egy részük le van mentve, de van ott még...) Hozzá lehet férni valahogy?
Van valami megoldás?
Köszönöm.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Mivel van titkosítva? Nézd meg a cryptsetup luksOpen-t, feltéve, hogy a titkosított partíció jelszava megvan.
Esetleg, ha a root nincs titkosítva, akkor a /etc/shadow-ban a usernév: utáni stringet törlöd a következő :-ig és megpróbálsz reboot után így belépni.
Utolsó emlékeim szerint ezzel jelszó nélkül lehet belépni.

Köszönm megnézem.

Szerintem a /etc/passwd lesz az, nem a shadow!


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mióta? :o
Lehet, hogy van olyan, ezt nem tudom, de a /etc/passwd-re mindenkinek van read joga, ezért került át anno a /etc/shadow-ba a kódolt jelszó, amit csak az illetékes processzek tudnak olvasni, pláne írni.

Ebben igazad van, de nem a jelszót kell megváltoztatni, elég neki azt mondani, hogy ne keresse a shadow-ban a jelszót, mert nincs. Ami meg nincs, azt nem kell beírni a login alkalmával. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyébként tökmindegy, mert a shadow-val is működik, ha működik.
Ha meg nem, akkor jöhet a chroot+passwd :)

A jelszó hash a shadow-ba van tárolva.

Ezt értem. Ahhoz, hogy ne kérjen jelszót, lényegében ilyesmi kell:

getent passwd root | awk 'BEGIN {FS=":";} {for (i=1; i<=NF; i++) { if (i!=2) printf("%s", $i); if (i<NF) printf(":");}} END {printf("\n")}'

Szóval azt az x-et, amely arra utal, hogy a jelszó a shadow-ban van, ki kell törölni, s akkor már semmi sem utal arra, hogy ott kell keresni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valóban.
Ez nekem kimaradt.
Arra emlékszem, hogy az üres jelszó nem mindig működik (pl. valamelyik display manager hajlamos volt nem beengedni attól kezdve, hogy töröltem a jelszót)

váltani egy másik virtuális konzolra? a /bin/login tudtommal nem szokott reklamálni.


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

Köszi, próbáltam, sintax error, majd holnap megnézem a könyvet. Mást próbálok, ha sikerül, elárom hogyan :-)

Ugy tunik nekem, hogy ket problemad van, amik egymastol fuggetlennek tunnek.

1) ha nem mukodik a felhasznaloi jelszavad, akkor root-kent keszits egy ujat!

2) ha a home konyvtar titkositott, akkor ugy mountold fel, hogy ezt kezeld kozben. Megfelelo parameterek, jelszo, stb. Hogy pontosan mit es hova, attol fugg, hogy hogyan titkositottad es mivel.

Az első probléma, hogy nem tudok belépni. (ez most másik) Csak a /home nem elérhető, ez telepítésnél
automatikusan titkosított, nem tudtam, mikor feltettem. Szóval először be kéne jutni.
A shadow-ban csak user: semmi, de nem jutok be.

Töröld ki a /etc/passwd-ből a root bejegyzésénél az x-et pl. egy live linuxról. Utána üres lesz a root jelszavad.

Tehát pl. volt:

root:x:0:0:root:/root:/bin/bash

Lett:

root::0:0:root:/root:/bin/bash


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm, próbálkozom. Üres jelszó nálam se jön be de szívós vagyok :-)

A /home mountolásakor kér jelszót?
Ha nem, és a luks van használatban, akkor a /etc/crypttab-ban a harmadik oszlop/mező a kulcsfájl, azt kiszedve a cryptsetup luksOpen segítségével meg tudod nyitni a /home-odat.

Kösz, megnézem ezt is.

Várj, kicsit (nagyon) félreérthetően fogalmaztam!
Nem törölni kell a kulcsot, hanem a crypttabban található helyről használni. Szóval a cryptsetup luksOpen-nek azt kel odaadni kulcsként.

Megnyitni meg tudom, de a file-ok nem láthatók. Eddig semmi nem jött be, jelszót sem tudom megváltoztatni, token error, root-ként se látni semmit a user könyvtárban. Egy biztos, Ultimate Linux soha többet.

Ha van még valakinek ötletem köszönettel venném. A home könyvtár megnyitható, de a tartalma nem látszik. Át is másplható, csak ugye láthatatlanul.. fel lehet ezt valahogy pattintani? A bejelentkezésre nem látszik semmi esély.

Nomostan az, hogy a /home látható, az nem vitás, hiszen az a / része. A /home alatti fájlrendszert egy titkosított kötetre rakta az OS, azt kéne látni, hogy mi van a /etc/fstab-ban, illetve a /etc/crypttab - ban. Ez alapján a cryptsetup szépen fel tudja csatolni a megfelelő kötetet.
Ha a /etc/crypttab-ban azt látod, hogy home "/dev/valami/valami none", akkor emlékezned kell a home titkosításához használt jelszóra - ha nem emlékszel, akkor az az így járás esete, értelmes idő alatt próbálgatva nem fog menni.
Ha valami krix-krax van ott, akkor a cryptsetup luksOpen /dev/home-ot/tartalmazó/device HOME parancs kérdésére azt kell majd válaszolnod, amit ott látsz.
Ez után a mount /dev/mapper/HOME /home szépen felcsattintja a "kinyitott" /home-ot a helyére. Ha a crypttab sérült, és amiatt nem megy az automatikus csatolás, akkor elő kell venni a crypttab mentését, és abból kinézni a passphrase-t, ha nincs mentés, és sérült, akkor goto "elfelejtettem/nem tudom a mounthoz a jelszót" eset.

A leírásod alapján nekem gyanús, hogy a root jelszót nem ismered, és a mounthoz szükséges jelszó sincs a birtokodban - ekkor szokott ugyanis az történni, hogy újraindítás után bekéri n-szer a cryptodiszk jelszavát, és ha nem megy, akkor single módhoz kéri a root jelszavát. Ezt lilo/grub/grub2 esetén is ki lehet kerülni úgy, hogy a boot folyamat egy root joggal bíró shell-ben érjen véget, de ennek a kiguglizását már rád bízom :-)

Köszönöm a választ. A home-ot én nem titkosítottam, ezt ez az állatfajta automatikusan így csinálja, home/user csak a luzeré.... Recovery mode-ban root-ként se találok ott semmit. Másik rendszerből chroot-tal ugyanez van.

cryptab:

UUID=ca95a66b-6183-448c-8c8d-047597b19273 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

fstab:

#
# / was on /dev/sda2 during installation
UUID=3fd0f947-0644-4514-8423-ac237d82c7e4 / ext3 errors=remount-ro 0 1
# swap was on /dev/sda6 during installation
UUID=ca95a66b-6183-448c-8c8d-047597b19273 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

Gpndoltam arra, hogy másik paticiora feltelepítem ugyanezt a rendszert, és a jelenlegi lenne a /home, formázás nélkül, csak esetleg így már 2x lenne titkosítva... nincs ötketem. Belépni nem lehet.

A crypttab ebből az egyetlen sorból áll? Jé... ilyet még nem láttam.

Az csak most esett le, hogy a $HOME van titkosítva. Amit akkor bont ki a rendszer, mikor bejelentkezel... na ilyet még sohasem csináltam.
Ha van rá pár napod, akkor megnézem egy virtuális gépben, hogy ez hogy működik.

Ugyan ez ubunturól szól, de talán segít: https://www.howtogeek.com/116297/how-to-recover-an-encrypted-home-directory-on-ubuntu/
Gyanítom, a te linuxod készítői nem találták fel újra a kereket, szóval akár egy Ubuntu live-val is működhet.

Hálásan öszönöm, táérek.

Ezt az ultimate bigyót honnan szedted le?

Distrowatch.

ISO-hoz nincs linked? (ahhoz, amit használsz)

A fő baj, hogy nem lehet bejutni. A bejelentezés kezelő darabjai merre vannak?
Feltelepítettem ugyanezt memoria kártyara, abból hátha ki lehetne hegeszteni...
Elég hisztis az Ultimate, de ere nem számítottam. Volt adatmentés, de nem napi, van veszteség bőven.
A live CD-s változaton dolgozom, még a leg ígéretesebb.

Akkor ehhez én nem is kellek:

"Ultimate Edition 5.5 was built from the Ubuntu 17.04 'Zesty Zapus' tree, using a combination of Tmosb "

A korábban linkelt leírás alapján az ubuntus live rendszernek is illene működnie.

Most írtam fel dvd-re, meglátom. Köszönöm.

Hát van egy szomorú hírem: ezt nem fogod tudni helyreállítani.
Úgy fest, hogy a titkosított home-nak a rendszer még telepítéskor generált egy kulcsot arra az esetre, ha elfelejtenéd a login jelszót. Azt meg kellett volna jegyezni ahhoz, hogy helyre tudd állítani a user saját passwordje nélkül.
Ha átírod a user jelszavát egy live rendszerről, akkor ugyan be tudsz lépni, de a GUI-ból rövid úton kivág, mert a $HOME-ot nem tudja dekódolni, így nincsenek meg a grafikus felülethez szükséges fájlok.
Viszont az ecrypt-recover* sem tud lefutni, mert ahhoz is kellene vagy a user jelszava vagy a telepítéskor megadott generálnyitó...

Áldjon meg az Isten mind a két kezével! :-)
Megvan itt minden.
Hálás köszönetem.

Hogy sikerült jelszavak nélkül? :o

Mert én itt felnyomtam egy ubuntu 17.10-et és hát... ez alaposan megvédte magát. :)

Live cd-ről, semmi más, csak ami a cikkben szerepelt, amit linkeltél. :-9

Még egyszer kösz.

Furcsa. Valamit elnézhettem, mert próbáltam úgy csinálni, mintha elfelejtettem volna a jelszavam, de úgy az ubuntut nem sikerült helyreállítani.

Úgy volt, hogy a sudo ecryptfs-recover-private kéri a jelszót, de esetemben csak 1 jelszó van, a useré, ezt nem fogadta el - itt se, csakúgy mint a bejelentkezésnél.

Az encryptfs-unwrap-passphrase rákérdez, kívánod-e kiásni a jelszavadat, lelkes yes, és kész. Ott van a /tmp-ben minden.

Utána még annyi macera van, hogy csak root-ként lehet áthúzni valahová, jogosultságokat át kell írni.

Ez egy elég gáz megoldás, ahogy olvasom. Az általad linkelt cikk azt mondja:
"You can still recover your encrypted files without this mount passphrase, assuming the ecryptfs wrapped passphrase is still available on your hard drive. However, if you lose this data or it becomes corrupted, you’ll need the mount passphrase to recover your files."
Magyarán a kulcs ott van a lábtörlő alatt, ergo 0 értelme van egy ilyen titkosításnak.

Nem ismerem ezt az Ultimate Linuxot, de nem tartom jó gyakorlatnak a felhasználó tudta nélkül titkosítani az adatait. Sok felhasználó fegyelmezetlen, nincs felkészülve a titkosításra, ami egyfajta felelősséget is kíván. Még ha tudnak is a titkosításról, akkor is elfelejtik a jelszót, meg természetesen, hogy ezen a teljesen laikus szinten mentés sem lesz, így meg majd jön a bőgés. Felelőtlenség ilyen felhasználókra rákényszeríteni, főleg a tudtuk nélkül.

Örülök azért, hogy közben megoldódott, remélem ez a fiaskó nem veszi el a kedvét a topikindítónak a titkosítástól, mert az jó dolog, csak nem ez a lófaszubuntus $HOME ökörködés, hanem egy tisztességes LUKS vagy hardveres ATA AES titkosítás, ami az egész meghajtót titkosítja, ami külön jelszóval nyitható (nem automatizált a feloldás belépéssel).

A hardveres ATA AES titkosítás különösen veszélyes, ha az ember nem jól csinálja, vagy elfelejti a jelszót (és nincs akkora szerencséje, hogy a mesterjelszót a BIOS generálta valami visszakövethető módon vagy default passworddel), nem csak az adatokat bukja, hanem az egész meghajtót is, kizárja magát belőle végérvényesen, se újraformázni, se hozzáférni, sem semmit csinálni nem lehet vele, az egész mehet bele a kukába, akkor is, ha hardveresen semmi hibája nem volt, különösen fájó lesz, ha pl. egy drágább SSD-ről van szó. Nincs ellene trükközés, nincs hátsó kapu, ha elfelejti valaki a jelszót, vagy a mesterjelszót is (ha van külön), akkor mindennek bukó, átgondoltan kell használni. Ez a fajta hardveres titkosítás ugyanis nem csak az adatokat védi, de a meghajtót is lopás ellen, hogy a tolvaj ne tudja a meghajtó újraformázásával azt értékesíteni, hanem látszani fog mindenképpen, hogy jelszóval van védve.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Ezen átsiklottam a jelek szerint. Ez így, ebben a formában tényleg gáz.

Abban teljesen biztos vagy, hogy a hardveres titkosítás nem resetelhető? Mert nekem úgy rémlik, a normálisabb BIOS-okban van lehetőség arra, hogy eltüntesd azt a jelszót, persze adatokkal együtt.

Ilyen esetben, amelyik bios-ban nincs meg ez a menekülő útvonal, az nem normális... illetve ha valaki így akar titkosítani, jó ha felkészül a folyamatos adatmentésre és előbb megnézi, létezik-e a bios-ban ez a lehetőség.

Szerintem ez nem akkora probléma. Mivel a gép sem varázsló, kell a kulcs a kititkosításhoz. Ugyanakkor senki sem mondta, hogy azt a vitatható értelmű formát kell hozni, miszerint a kulcsot az adatok mellé - ha úgy tetszik, a lábtörlő alá - kell tenni. Lehet a titkosító kulcs például egy pendrive-on külön, s akkor esélytelen a titkosított adat visszahozása nélküle. Ha gyengébb védelem is elég, s csak úgy kell védeni a HDD-t, hogy kilophatják a gépből, akkor lehet a kulcs ugyanazon a gépen azon az SSD-n, amelyen az oprendszer van. Itt feltételeztem, hogy a /home viszont a HDD-n van.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én problémásnak érzem, mert amikor ezt bekapcsolod telepítéskor (ubuntu), kihány magából egy random stringet a képernyőre, ami mellé kiírja, hogy vésd fel valahova. Egyébként a user saját passwordje nyitja a home-ot.

Ha ezt kötelezően csinálja, szembesít vele, az nagyon rossz. Fedorán a mount point-ok kialakításánál, a filerendszerek megválasztásánál van arra lehetőség, hogy titkosítást válasszon az ember. Egyáltalán nem tolakodó, egy checkbox, ha beteszed a pipát, titkosított lesz.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ubuntun is ez van és mondom: vagy kihagytam egy lépést, vagy a szóbanforgó rendszer csinálja másképp, mert nekem nem sikerült visszanyerni a home-ot, ha elfelejtettem a jelszavam és a telepítéskor kirakott kódot is.

De, ha jól sejtem, ez az Ultimate Linux valami más, mint az Ubuntu.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy ubuntu alapú rendszer.

Úgy vagyok ezzel, hogy ezeknek vajmi kevés jelentősége van. Ugyanazok a nyílt forrású alkalmazások és függvénykönyvtárak vannak mindenhol. Az eltérés pusztán az egyéni fejlesztésű eszközökben mutatkozik meg. A telepítő és csomagkezelő épp ilyen.

Annyira megszoktam, hogy a munkahelyi windows-os gépemen a WSL-ben futtatott Ubuntu userspace-nek azt mondom, hogy apt update, majd apt upgrade, az itthoni Fedoráimon meg dnf upgrade. Vagy semmit, mert bekonfiguráltam, hogy legyen autoupdate.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

„Fedorán a mount point-ok kialakításánál, a filerendszerek megválasztásánál van arra lehetőség, hogy titkosítást válasszon az ember. Egyáltalán nem tolakodó, egy checkbox, ha beteszed a pipát, titkosított lesz.”

Most megnéztem, hogy magamnak ezt az Ultimate Edition-t. A telepítésnél itt is be kell rakni a pipát a titkosításhoz.

Akkor lehet, hogy az egész topic csak RTFM? :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azokon a gépeken, amiken hd titkosítást használtam, bootolás előtt bekéri a jelszót.

Ha nem nálam van a gép, akkor lehet találgatni.

Nem érzem azt, hogy ha a titkosítás az én jelenlétem nélkül feloldható (mert a kulcs megvan a hdd-n valahol), akkor az olyan nagyon biztonságos lenne.

Mondjuk a magán gépemen nem használok titkosítást, a céges gépnek a mester jelszavát meg tudja az IT.

Igazából nem tudom, hogyan működik, de szerintem a jelszó meg a kulcs nem ugyanaz. Úgy értem, lehet ezt nem túl biztonságosan implementálni: kulcs=f(jelszó), tehát el bírok képzelni olyan lehetőséget, hogy a jelszóból generálnak kulcsot, a HDD tartalmazza szintén azt, egyezőség esetén a kulccsal kititkosít. Ekkor a kulcs megkaparintása elég lehet a titkosítás feloldásához.

Persze semmi okom feltételezni, hogy ezt ilyen ügyetlenül oldanák meg.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze, hogy nem lenne biztonságos a kulcsot eltárolni a titkosított adatok mellé. Ezért nem vagyok híve annak a megoldásnak sem, hogy egy másik meghajtón, pendrive-on, akármin legyen a kulcs, mert hiába kényelmesebb, nagyon megkönnyíti a támadó dolgát. Ugyanez a baja az ujjlenyomattal titkosításnak is. Ugyanezért nem jó a jelszót cetlire felírni. Ha a kulcs csak az ember fejében van, akkor a tudta nélkül nem lehet megszereznie illetéktelennek. Tudom, kényelmetlen minden bootkor jelszót beírni, de az adatbiztonság megéri, és hozzá lehet szokni.

A modern titkosításoknál meg alapelv, hogy nem tárolják el a titkosított adatok mellett a jelszót, az nagy balfaszság lenne, az egésznek a létjogosultságát ásná alá, értelmetlen lenne úgy titkosítani. Csak az nem törné fel úgy, aki nem akarja.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

LUKS? Nem modern, nem biztonságos vagy csak az a baj, hogy fogalmam sincs, hogy működik?
(Utóbbi tény :) )
Csak úgy jön ide, hogy (legalábbis az általam ismert felállásban) úgy működik, hogy minimum egy, maximum nyolc(?) jelszót lehet megadni a titkosítás feloldására és ezek bármikor változtathatóak. Feltételezem, van egy kulcs, amivel az adatokat kódolja és a jelszavak ezt a kulcsot nyitják. Ha ez tényleg így van, akkor a kulcsnak ott kell lennie a titkosított adatok mellett. (Bocs úgy két éve találkoztam vele először, használni használom, de a belsejét sosem néztem meg, most meg félkómásan jobb ha nem kezdek neki ;) )

feliratkozás

Mindenkinek köszönöm a segítségét.

Elvi szinten megközelítve a problémát: Mi értelme van az olyan titkosításnak, aminek a jelszó nélküli feloldásához az interneten lehet találni módszert?

Semmi, de erre mondtam, hogy értelmessé válhat ez akkor, ha a kulcs fizikailag másik eszközön van. Mondjuk úgy valóban értelmetlen, ha az átlagos felhasználót kötelezi a titkosításra, de a kulcsot alapértelmezetten az adat mellé teszi. Így csak az adatvesztés esélye lesz sokkal nagyobb.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pontosan, ráadásul nem is opció, a megkérdezésem nélkül automatikusan így telepít, nem is tiudtam, hogy titkosított a home.

Amikor kipróbáltam VirtualBox-ban, akkor külön be kellett jelölni, ha titkosított telepítést akartam. De úgy tűnik, másnál is így volt: (5. kép)
https://www.linux.org/threads/ultimate-edition-5-4.4565/

Bő fél éve tettem fel, őszintén szólva nem emlékszem, de soha nem használtam titkosítást, otthoni gépen, ahol nincs érzékeny adat, semmi értelme. Itt a fő probléma az volt, hogy be se tudtam lépni.

Azért ezt nem jelenteném ki, hogy nincs értelme otthoni gépen. Ráadásul AES-NI nélküli procival sem lassít sokat, kisebb egy AES256 XTS LUKS overheadje, mint az ntfs-3g-é titkosítatlanul. AES NI-s CPU-val meg hardveres AES ATA titkosítással meg pontosan 0% az overheadje. Sokkal inkább csak a felelősség, ami vele jár, azért nem jó ötlet egyszeri felhasználóra rátukmálni, főleg nem a tudta nélkül, ilyen sunyi bejelentkezéssel automatizált mechanizmussal.

Mondjuk azt sem értem, hogy egy ilyen n+1. uborkaklónban mi a vonzó, ami miatt valaki felteszi. Ha annyira Ubuntu-alap kell, akkor érdemesebb Ubuntut feltenni, és kiismerni azt, több értelme van, mint egy még kisebb, ismeretlen vagy noname disztró különcségei miatt szívni.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Természetesen van értelme, ha van valami érzékeny adata agépen. =Nálam nincs.)
Ezt az uborka ultimate-et kalandvágyból próbáltam ki. Sok disztrót telepítettem már,
a gépcsere ehgy jó alkalom volt, végül ez maradt. A sebességkülönbség nem jelent gondot,
az ultimate alapból viszonylag lasú, felesleges, bosszantó és néha veszélyes szolgáltatásokban gazdag,
minden memoriát felzabál.
Még mindíg visszasírom a Debian 3-at. Most egy puritán Debi klon fut. jó.

kalandvágyból

Akkor mission accomplished, a kaland megvót :D

+1

Várj, megvan!

El lehet adni pénzért a support szolgáltatást az embereknek.

su