- Megérkezett a Google Pixel 7 és 7 Pro
- iPhone topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Google Pixel topik
- Poco M3 - felújított állomás
- Térerő gondok, tapasztalatok
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Honor Magic6 Pro - kör közepén számok
-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
-
-
-Ben-
veterán
-
Akkor a modulok elméletileg betöltődtek.
Ezt írja amúgy a detect végén:
Monitoring programs won't work until the needed modules are
loaded. You may want to run '/etc/init.d/kmod start'
to load them.
Unloading cpuid... OK'/etc/init.d/kmod start'- így nem fut le'/etc/init.d/kmod'- így meg lefutFene se érti.
ezzel csak a fan-t figyeli a terminal, 1 mp frissítéssel:
watch -n 1 "sensors | grep fan"
-
Parancssorosan nem tudom.
Én úgy futtattam akmod-ot, hogy a fájlkezelőt megnyitottam rendszergazda módban (jobbgombos katt), elnavigáltam az/etc/init.dmappába, onnan nyitottam egy terminalt és abba behúztam akmodfájlt és nyomtam egy Entert. Ha csak simán beírtam, akkor nem futott le.
akkor jó, ha azt írja ki, amit itt is:
root@ubymint19cv2:/etc/init.d# '/etc/init.d/kmod'
* Usage: /etc/init.d/kmod startHa ilyen félmacskakörmökkel írod, akkor is lefut rendesen,
/etc/init.dmappán belül persze :'/etc/init.d/kmod'
-
válasz
Frawly
#64183
üzenetére
Nincs már kdesudo a 18.04-ben, és a kdesu is csak végbéltükrözéssel elérhető, kasztrált és ráolvasásokkal ördögűzésen átesett változatban. Egyszerűbben fogalmazva a GUI-s fájlkezelők nagy általánosságban páriák, ha neked bármiért olyan fájlt kell(ene) macerálni, amihez root jog kell, akkor ahogy nézem, a legtöbb, amit nyújtani tudnak az, hogy felajánlják a konzolban megnyitást opciónak...
-
-
Frawly
veterán
Ez ilyen. A scripteket terminálhoz tervezték. Elvileg vannak olyan scriptek azért, amelyek grafikus ablakokat meg GUI-t nyitogatnak (pl. Loki játéktelepítők), de az ritka, meg épp úgy vannak grafikus installerek is.
Egyébként nehogy azt hidd, hogy a Windows annyival egyszerűbb, ott is néha könyékig kell turkálni a Registryben, mindenféle Csökkentett és Visszaállítási/Javítókonzolos Móddal szívni, átlag felhasználó épp úgy nem tudja abszolválni, mint a linuxos terminálos dolgokat. Csak a Windowsnak elnézik, mert azt ismerik, megszokták már, meg a szomszédnak is az van, meg könnyebb hozzá segítséget szerezni.
A jogokra meg figyelni kell mindenképpen, nem csak Double Commanderben, de terminálban is. Elvileg a DC-t is indíthatod rendszergazdaként (gksu vagy kdesu, vagy hasonló megoldással), meg attribútumokat is szerkeszthetsz vele jogosultságkezelésnek. Egyet nem tud csak azt hiszem, fájl/mappa tulajdonost cserélni, arra tényleg csak terminálban tudok megoldást.
Linux alatt meg azért fontosabbak a jogosultságok, mert pl. nem számít a kiterjesztés. A ./install scriptről alapból a Linux azt hiszi, hogy csak egy szövegfájl, amiben az élettörténeti regényed van begépelve. Azt, hogy ez tényleg futtatható script, azt úgy kell neki mondani azzal, hogy futtathatóvá teszed. Sőt, még gyakran ez sem elég, azért szokott lenni a script első sorában a #!/bin/bash, hogy tudja a rendszer, hogy a scriptet a Bash fogja interpretálni. Ha ez a fejléc nincs benne, akkor megpróbálja binárisként futtatni, majd visszajön egy hibaüzenettel, hogy hibás ELF formátum vagy valami hasonló. A logikája más, mint a Windowsnak, utóbbi a kiterjesztésből nézi meg, hogy mivel kell megnyitni a fájlt, ha .exe, akkor elindítja a kernel, ha .bat, akkor parancssori értelmezővel nyitja meg, így nem kell sem fejléccel, sem futtatható tétellel bajlódni.
Bár terjed most már Linux alatt is, hogy amit ilyen driverekhez, forráskódhoz csomagolnak scriptet, azok már alapból futtathatóvá vannak téve. Régen elterjedtebb volt, hogy szándékosan alapból nem volt futtatható, biztonsági megfontolásból, de aztán rájöttek, hogy a sok Linux noobbal felesleges kiszúrás.
-
@ubyegon2: Ez most dícséret vagy kritika?
@Frawly: Igazából a Linux vs. Windows viták fő kerékkötője az szokott lenni, hogy lehet-e GUI-ról kezelni a rendszert, vagy nem. Én még mindig csak tanulom a linuxot, de akármennyire is szeretek benne sok dolgot, azt nem lehet elvitatni, hogy konzol (terminál) nélkül bizony folyamatosan falakba ütközne az ember.
Amikor valakinek felrakok egy Linuxot (gyenge vas, vagy általános Windows-mentesítés miatt), mindig attól parázok, hogy valami olyasmibe fut majd a felhasználó, amit nem tud maga megoldani, mert általában ez, vagyis a terminálban való bírkózás az, ami az egyorrú Windows-felhasználókat elbátortalanítja.
Az elmúlt két napban azzal szivattam saját magam, hogy először ownCloud, majd Nextcloud telepítés és konfigurálást csináltam, mondván legyen saját felhőm! Aham. Az ownCloud még istenes volt, sikerült feltelepíteni, bekonfigurálni, még működött is, csak éppen a 10-estől kezdve nincs rá mód, hogy betallóz egy komplett meghajtótt (biztonsági okokból, az owncloud admin ugyanis így admin jogokhoz jut a linux alatt is). Na mondom itt a fork, a Nextcloud, na az majd... na, attól majdnem kihullot a maradék hajam, mert először nem sikerült megoldani, hogy az Apache beengedjen. Némi szívás után végre eljutottam oda, hogy localhost alól elértem a kezelőfelületet - ami közölte, hogy belső szerverhiba (internal server error), és ennyi. A logokhoz nem sikerült double commanderrel hozzáférnem (nincsjogodhozzáhaakarszvalamitmajdterminálbólelintézed...), és itt közöltem, hogy jó, az önszivatásból ez úgy elég volt...
-
Frawly
veterán
Nem nagyon van alternatíva. Elméletileg futtathatod grafikus felületről is, de ha a script valami megerősítést, billentyűleütést, választ vár, vagy kiír valami hibaüzenetet, azt nem fogod látni. Ezért a scripteket mindig terminálból vagy konzolból kell futtatni, erre vannak tervezve. Tudom, kényelmetlen terminált előszedni, a telepítőmappára átváltani, majd a sudo ./install karaktersorozatot végiggépelgetni, de így legalább biztosra mész.
-
Te vagy az első KDE használó, aki nem lefitymálóan gondol a Nemo-ra!
Ahogy nézem, 19.1 Mint-nél az a pont, ahonnan a Cinnamon Nemo páros már csúcson van.
7etape
A sensors-detect lefutása végén van, hogy a kmod-od is futtatni kell az /etc/init-d mappából rootként.
Lehet, hogy a tlp csomagot kéne felraknod és megnézni, reboot után nem lesz-e jobb.
-
-Ben-
veterán
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +20.0°C (high = +81.0°C, crit = +101.0°C)
Core 1: +23.0°C (high = +81.0°C, crit = +101.0°C)
Core 2: +19.0°C (high = +81.0°C, crit = +101.0°C)
Core 8: +21.0°C (high = +81.0°C, crit = +101.0°C)
Core 9: +18.0°C (high = +81.0°C, crit = +101.0°C)
Core 10: +17.0°C (high = +81.0°C, crit = +101.0°C)
it8720-isa-0290
Adapter: ISA adapter
in0: +1.18 V (min = +0.00 V, max = +4.08 V)
in1: +1.54 V (min = +0.00 V, max = +4.08 V)
in2: +3.34 V (min = +0.00 V, max = +4.08 V)
+5V: +3.02 V (min = +0.00 V, max = +4.08 V)
in4: +0.00 V (min = +0.00 V, max = +4.08 V) ALARM
in5: +3.01 V (min = +0.00 V, max = +4.08 V)
in6: +0.02 V (min = +0.00 V, max = +4.08 V)
5VSB: +3.04 V (min = +0.00 V, max = +4.08 V)
Vbat: +3.10 V
fan1: 1493 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 1218 RPM (min = 0 RPM)
fan4: 1225 RPM (min = 0 RPM)
temp1: +29.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +28.0°C (low = +127.0°C, high = +127.0°C) sensor = thermal diode
temp3: +44.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
intrusion0: ALARMSikerült idáig eljutnom. Most jön viszont az, hogy valahogyan be kellene állítanom a fordulatszámokat, mivel jelenleg bőg az egész gép. (Hangosabbak lettek hűtők)
-
@ubyegon2: Köszi, az első fájlkezelő, ami Kubuntu 18.04-en tud fájlt futtatni... Vakok között félszemű a király.
@lev258: Dolphin és Nautilus esetében, valamint Double Commandernél nem találtam ilyet. Nemo esetében igen.
-
-Ben-
veterán
válasz
ubyegon2
#64174
üzenetére
Nem tudom. Valamilyen egyszerűbb leírást keresek, mert ez eléggé kínai.
Szerk.: igen, a detektálás volt. Jelenleg ennyit lát a sensors:
benji@benji:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +20.0°C (high = +81.0°C, crit = +101.0°C)
Core 1: +24.0°C (high = +81.0°C, crit = +101.0°C)
Core 2: +20.0°C (high = +81.0°C, crit = +101.0°C)
Core 8: +21.0°C (high = +81.0°C, crit = +101.0°C)
Core 9: +20.0°C (high = +81.0°C, crit = +101.0°C)
Core 10: +17.0°C (high = +81.0°C, crit = +101.0°C) -
lev258
veterán
Jobb gomb, Tulajdonságok, Jogosultságok
Ott lesz valami a futtatásról. Ismétlem, a jelszó igény bekavarhat. Annak kérését nem mindig építik bele magába a telepítőbe.
Az ilyen "felfrissítem dolgok" mindig meggondolandóak. Pontosan meg kell nézni, milyen komponensek mellett tud sikeresen települni. -
-
-
Most látom, hogy kéklufi is ezt írta, de az enyém Debian 9-es csomag legalább.
![;]](//cdn.rios.hu/dl/s/v1.gif)
ez csak kiegészítés:
Most Effective Ways To Reduce Laptop Overheating In Linux
TLP – Quickly Increase and Optimize Linux Laptop Battery Life -
Megint lenne egy naiv kérdésem: adva van egy Mellanox hálózati kártya driver. Kitömörítem, benne egy install fájl. Namost ezt hogy a hóbelevancba tudnám én futtatni fájlkezelőből? Igen, azzal tisztában vagyok, hogy konzol ->
sudo ./install. De tényleg csak ez az egy megoldás van erre?
-
HW-es megoldás is lehetséges, pl. Yubico. Igaz Windows-ra létezik az USB raptor, ami egy mezei pendrive-ból készít "kulcsot", de tuti van linux-os megfelelője is. Vagy a proximity. Igaz egy ideje nem fejlesztik, de képes rá hogy ha az adott bluetooth eszköz a közelben van, végrehajtson bizonyos parancsokat, ill., ha eltűnik futtasson mást. Ezzel megoldható a titkosítás automatikus feloldása, ha a telefonod a közelben van.
-
Frawly
veterán
Azért nem biztonságos csak néhány mappát titkosítani, mert a titkosítatlanul futó rendszerben, egyéb partíciókon, mappákban, swapban, azaz a titkosítatlan részeken marad nyom a titkosított adatokról, arról az állapotról, mikor fel vannak oldva a titkosítás alól és meg vannak nyitva.
Illetve az ilyen fájlrendszer alapú titkosítást könnyebben törik elméletileg mintázati támadással. Ha az egész lemez/partíció van titkosítva, min. XTS-sel, akkor nem tudják, hogy melyik rész a lemezen szabad, melyik foglalt, milyen-hány fájl van rajta, milyen fájlrendszer egyáltalán.
A legjobb, ha az egész rendszer, egész meghajtó van titkosítva. Nincsenek titkosítatlan részek egyáltalán.
Ezért gyengébb SSD-t is titkosítani. A hardveres titkosítás tényleges törhetősége gyártói implementációfüggő (ezért kevésbé biztonságos, mint mondjuk a szoftveres, nyílt forráskódú Luks), vagy ha szoftveres titkosítást használsz rajta, akkor meg a TRIM-et ki kell engedni rajta, de az meg megint a mintázati támadást segíti.
De a Bitlocker is eleve ezért kevésbé biztonságos. Pedig lehet technikailag nem kevésbé biztonságos, de mivel zárt forráskód, nem látod mit hogy implementáltak benne, vannak-e hátsó kapuk (valószínűnek tartom, hogy nincsenek), stb..
Pl. a körülményektől is függ, hogy mennyire biztonságos titkosítani. Tegyük fel több felhasználó is van a gépen, amin hardveres vagy szoftveres egész lemezes titkosítás van. Legalább a rendszermeghajtóhoz mindegyik felhasználónak ismernie kell a jelszót. Minél többen tudják, annál valószínűbb, hogy valamelyik valahová felírja, valahol kikotyogja, valakivel megossza, valakiből kiszedik.
-
Frawly
veterán
válasz
anorche1
#64156
üzenetére
Ezzel a megoldással nem az a baj, hogy Windowst érint. Az a baj ezzel a fajta kényelemmel, hogy mikor nem írsz be jelszót, hogy bárki odaül a gép elé, és annak sem fog kérni, szépen hozzáfér mindenhez. Ennek így nincs értelme, mintha az ajtót zárnád, de a kulcsot a zárban hagynád vagy a lábtörlő alatt.
Egyébként megértem, hogy sok ember nem szereti a jelszót, meg a titkosítást. Kényelmetlen, nem elég fegyelmezettek hozzá, lusták jelszót gépelgetni, elfelejtik a jelszót, vagy épp ellenkezőleg, kiírják cetlire amit a gépre/monitorra ragasztanak, visszajutunk a kulcs a zárban metaforához.
Titkosítani rendesen/hatékonyan érdemes vagy sehogy. Úgy, ahogy megkezdődik a fetrengés, hogy könnyítő körülmények legyenek, csak egy, meg csak az legyen titkosítva, jajj, csak jelszót ne kérjen, szépen megy le fokozatosan az egész értelme a lefolyón.
-
Rimuru
veterán
válasz
anorche1
#64156
üzenetére
Annak nincs értelme hogy titkosítasz de nem kér semmi interakciót feloldáshoz (jelszó, pendrive, yubikey, stb), egyszerűen nem biztonságos ha lokálisan valahol ott van a feloldáshoz a kulcs...
Ez olyan hogy van egy széfed de mellete sticky noteon ott a PIN, innentől ki az aki nem fér hozzá? (az aki nem akar)
-
#64158
ArthurShelby
addikt
CPT.Pirk
#64125
-
anorche1
őstag
válasz
Frawly
#64154
üzenetére
Linux alatt nincs bitlockerhez hasonlo megoldas? Ott nem kell minden bekapcsolaskor bepotyogni a jelszot, csak ha megvaltozott a hardver (pl. attettek masik gepbe a winyot).
Raadasul bitlocker -hez nem is kell se ujratelepiteni a rendszert, sem ujraparticionalni.Nem trollkodas, mielott valaki felreertene, es lereagalna azzal, hogy akkor miert nem hasznalok inkabb wint. Tenyleg erdekel a dolog, de mikor kiprobaltam a luks -ot nagyon zavart, hogy minden egyes bekapcsolaskor kerte a jelszot. Raadasul ha elutottam, nem is kerdezte meg ujra. Biztos lett volna parancs, amivel ujra megkerdezi, de nem foglalkoztam vele, mert szamomra ebben a formaban inkabb nyug.
-
Frawly
veterán
Megadhatod ugyanazt a karaktersorozatot mindkét jelszónak, de akkor sem fognak megegyezni, mert máshoz való jelszavak lesznek.
SpongyaGyurmaBoB-nak persze igaza van, lehet olyat, hogy user accounttal titkosítasz mappát, de ott tényleg szopó lehet egyrészt, hogy ha az user jelszót meg kell változtatni vagy újra kell telepíteni a rendszert, meg kevésbé is biztonságos. A LUKS viszont a saját jelszavával mindig felnyitható marad, tekintet nélkül újratelepítésre, gépre, platformra (Windows, BSD alatt is feloldható).
-
BoB
veterán
"azt hittem, hogy megoldhato az, hogy a titkositott HDD jelszava megegyezik a user jelszoval, es valahogy megoldhato, hogy eleg legyen egyszer megadni a bejelentkezeskor"
Jól hitted, lehet ilyet. Titkosított mappával meg lehet csinálni és ahogy olvastam ez pont az amire neked szükséged van, teljesen felesleges a teljes lemezzel megcsinálni.
Erre GNOME-on (ha jól emlékszem azt használsz) ott van az encfs + GNOME-keyring (opcionálisan + Gnome Encfs Manager ami GUIs).
Lásd továbbá: [link]
-
#64152
-Ben-
veterán
Black&White
#64150
-Ben-
veterán
válasz
Black&White
#64150
üzenetére
Jó kérdés. Debian -ra létezik valamilyen hűtő állítgató, amivel lejjebb vehetném a fordulatszámot? Már az is nyerő lenne, ha a VGA -t és a CPU -t lejjebb tudnám venni. Teljesen feleslegesen pörögnek 80% -on.
-
válasz
hódmaci
#64149
üzenetére
Az én példámban a [username2] ugye linux felhasználó volt, tehát neki a linux alatt célszerű megváltoztatni a jelszavát. Ezt konzolból így változtathatod meg:
sudo passwd [username2]A [username1] esetében csak samba felhasználót csinálunk, ez megváltoztatható konzolból így:
sudo smbpasswd [username1]Nem kell a -a kapcsoló, mert nem új felhasználót hozunk létre.
Igazából több megoldás is van, például lehet csak samba userekkel játszani, és az ő jogosultságaikat befolyásolni.
Egy javaslat:
Ha GUI megoldást keresel, tedd fel például a webmin nevű alkalmazást (
sudo apt-get install webmin), abban mindezt meg tudod csinálni - csak sajnos angol tudás kell hozzá, mert magyarul nem tud... -
#64150
Black&White
addikt
Black&White
addikt
Elképzelhető, hogy a korábban teljesen jól működő fancontroll csomag az újabb kernelekkel már nem működik együtt?
Az utóbbi hetekben kipróbáltam pár disztrót (Manjaro, Mint 19.1, Antergos) de egyik alatt se tudtam bekonfigurálni. Míg korábban egy Mint 18 telepítéssel minden rendben volt.
Arcwiki után mentem, ha ez számít és egy A85x chipsetes géppel van a szívás.
Ha hazaértem több infót is tudok adni. -
hódmaci
senior tag
Szia!
Ez nem "egy példa" hanem a megoldás.
Köszönöm.Esetleg ha valamikor meg szeretném valamely felhasználó jelszavát változtatni akkor ismét össze kell hoznom konzol paranccsal?
sudo smbpasswd -a [username1]Vagy csak elég ha a felhasználó megváltoztatja a jelszavát és ezzel automatikusan csatolódik a samba-hoz a jelszó?
Illetve egyszerűbben: a samba belépési jelszavát hogyan tudom változtatni [username1] vagy [username2] felhasználóknak?
-
válasz
Frawly
#64141
üzenetére
Frawly + tobbiek: Koszi a valasozkat, mar kezdem erteni.
Az okozta a kavarodast a fejemben, hogy azt hittem, hogy megoldhato az, hogy a titkositott HDD jelszava megegyezik a user jelszoval, es valahogy megoldhato, hogy eleg legyen egyszer megadni a bejelentkezeskor.
Igy, ha a user jelszot kivulrol megvaltoztatjak, akkor az mar nem lesz ervenyes a titkos HDD-re.
De vegulis inditasonkent +1 jelszo beiras nem veszes, es igy a biztonsag is meg van oldva. -
Laszlo733
aktív tag
Sziasztok!
Linux Mint 19 -et használok és Conky témában kérnék segítséget:
Az árfolyamok és a gmail beállításával már sok időt eltöltöttem, de eddig még nem sikerült megoldanom.
Az árfolyamoknál a zászló megjelenik, de maga a az árfolyam nem.
a myconfig.rc be ez van betéve:
${font Ubuntu:style=Bold:pixelsize=11}${image /home/név/Képek/Flags/24/United-States.png -p 0,0}${goto 3}${execi 30 /home/név/scripts/usd-huf.sh}
A home/név/ könyvtárban van egy Képek és egy scripts fájl is a megfelelő tartalommal.
A gmail esetében a scripts könyvtárban egy python scripts van és a myconfig.rc következő tartalommal:
GMAIL:
${hr}
You have ${color3}${texeci 60 python ~/scripts/gmailToConky.ph} ${color}new gmail(s).Mit nem csinálok jól, hogy nem akarnak működni?
Köszönöm előre is.
-
Rimuru
veterán
válasz
sh4d0w
#64144
üzenetére
Azért átgondolnám, a lényeg hogy Bici hozzáférjen és más ne, így lokálisan nem tárolódhat a kulcs, felhőbe rakni max úgy ér ha feloldásnál magától letölti egy script (lemezre így se menteném, vagy minimum shred utána ) és minimum two factor mögé raknám a kulcshoz való hozzáférést.
Bici: nekem is van egy ilyen "konténerem" munkahelyi gépen, abba a havi 1-2 jelszó beírásba nem halok bele (nincs kikapcsolva/suspend)
-
válasz
hódmaci
#64130
üzenetére
Itt nem a gépeken lesz a hangsúly, hanem a megadott felhasználó / jelszó pároson.
Az smb.conf file-t kell megfelelően paraméterezni. Erre több opció is van, itt van egy példának, az smb.conf fileba valami ilyesmi kell
[share]
path = [könyvtár elérés, pl. /mnt/share]
guest ok = no
read only = yes
write list = [username2]
valid users = [username1], [username2]
create mask = 0755A [username2] tud majd írni a könyvtárba, a [username1] csak olvasni tudja. Először hozzuk létre a linux felhasználó [username2]-őt, konzolba tehát:
sudo useradd [username2]Ez után állíts be neki egy jelszót:
sudo passwd [username2]Aztán a könyvtár tulajdonosává változtatod az írásra jogosult linux felhasználót, konzolba:
sudo chown [username2] [könyvtár]A csak olvasni tudó [username1] felhasználót a
sudo smbpasswd -a [username1]konzolparanccsal hozod létre.
Így a [username2] felhasználóval lehet írni, a [username1] felhasználóval csak olvasni az adott könyvtárban.
-
Frawly
veterán
Még egy gondolat. Kelleni nem kell semmit. Nem kell SSD-t titkosítani. HDD-t sem. Nem tart senki pisztolyt a bordáid közé. Te tudod, hogy neked milyen szintű biztonság kell, mire van szükséged, annak megfelelően döntsd el, hogy milyen részek legyenek titkosítva, és milyen titkosítási módszerrel (hardveres jelszó, szoftveres LUKS, stb.).
A titkosítás ilyen, kényelmetlenséggel jár. Persze feláldozhatod a kényelmet a biztonság oltárán, akkor a biztonságossági faktor csökken. Mindenkinek máshol van a két szélsőség között az arany középút.
Én régen minden HDD-men LVM-over-LUKS-ot használtam a rendszerlemezen, és LUKS partíciót az adatlemezeken. Aztán a rendszerlemezeim SSD-k lettek, azokon hardveres titkosítást használok (SATA SSD-ken ATA jelszót). Viszont 1-2 külső HDD-n természetesen megmaradt a LUKS. Teljesen megszoktam. Bootkor 1-2 mp. begépelni a jelszót. Plusz ha külső HDD-t csatlakoztatok nagy ritkán, akkor be kell írni még egyet. Nem halok bele. Már vagy 4 éve minden meghajtóm titkosítom. Kivételek ugyan vannak most, OS installálós, pendrive-nak használt SSD-ken nincs jelszó, de azokon érdemi adat sincs, meg egy mSATA SSD-n, amin csak Windows meg némi játék van, azon sincs titkosítás. Ennek az az oka, hogy ezek az SSD-k nem támogatják a hardveres titkosítást, a szoftvereset meg nem erőltetem rájuk, főleg, hogy nincs rajtuk semmilyen olyan egyéni adat, amit védeni kéne.
Plusz az SSD-k nem szeretik a szoftveres titkosítást. Ennek az az oka, hogy szoftveres titkosításkor az egész meghajtó telinek látszik, tele van pszeudórandom adattal. Persze a fájlrendszeren lehet szabad hely, de alacsony szinten az SSD vezérlője úgy látja, hogy tele van a meghajtó, és ezért nem tudja rajta az adatokat a cellák egyenletes fárasztása miatt pakolgatni. Vagyis van rá lehetőség, ha átengeded a titkosítási rétegen a TRIM-et, NVMe-nél még elvileg ez sem kell, mert ott a trimezést egy kombinált írási-törlési utasítás végzi. De az SSD-k akkor sem nagy barátai a szoftveres titkosításnak, sok azért is van felszerelve a hardveres titkosítási lehetőséggel, igaz ahhoz az alaplapnak is kell támogatnia, már pedig asztali lapok nem nagyon szokták, inkább laptopok, azok közül is inkább csak az üzleti kategória. Az SSD-k mindenképp más műfaj titkosításügyileg, mindenképp van velük szopófaktor valahol. HDD-t viszont mindenképp megéri titkosítani.
-
Frawly
veterán
Nem egészen értem mit akarsz, mintha kevernéd a dolgokat. A felhasználó jelszava nem egyenlő a titkosított partíció jelszavával. Mind a kettőt be kell írnod egy ponton (már ha nem csinálsz automatikus bejelentkezést, de az megint nem biztonságos). Kétszer viszont nem kell egyiket sem. HDD-nél választhatsz, hogy automatikusan csatolódjon bootkor, ilyenkor a bootkor kell beírnod a HDD jelszavát, vagy utólag csatolod fel filemanagerből vagy gvfs-ből, akkor bejelentkezés után kell beírni.
Esetleg lehet úgy, hogy jelszóbeírás helyett valami pendrive-ról kulcsfájlt használni, de az kevésbé biztonságos, mert ha valaki megszerzi a drive-ot, akkor hozzáfér az adatokhoz. A jelszó csak a fejedben van meg (ideális esetben), így azt senki nem tudja megkaparintani. Viszont kényelmetlen, hogy mindig be kell gépelni, de a kényelem és a biztonság mindig is ellentétes fogalmak.
De mondom, ha olyan az SSD, tudhat hardveres titkosítást is, azt BIOS-ban kell beállítani (vagy lehet linuxos hdparm-mal is, de nem ajánlom neked, ha nem vagy tisztában dolgokkal, mert hdparm-mal haza lehet vágni az SSD-t, meg ki lehet zárni magad belőle végleg). A hardveres SSD titkosításnak ez az egyik hátránya, ha elfelejted a jelszót, reszeltek az egész SSD-nek, többet nem tudod használni, nem csak az adatokat bukod. Szoftveres titkosításnál ha el is felejted a jelszót, akkor csak az adatokat bukod, magát a meghajtót bármikor újra tudod particionálni, a partíciókat újra titkosítani, stb..
-
válasz
Frawly
#64139
üzenetére
Na, most kezd akkor bonyolodni.
Az a cel, hogy a notiban levo nvme-s SSD-t ne kelljen titkositani, es a HDD-n levo titkositott particio-t akkor se lehessen elerni, ha ellopjak a notit.
Az SSD-n semmi fontos adat nem lesz, csak progik.
Azt mondjuk meg akarom oldani, hogy a bejelentkezesi jelszo beirasa utan ne kelljen a titkositott HDD hozzafereshez ujbol beirni jelszot.Ez igy megoldhato?
-
Frawly
veterán
Igen, hozzáférsz a titkosított kötetekhez, akkor is, ha a felhasználói, rendszergazdai jelszót megváltoztatod, ergo nem úszod meg az SSD titkosítását, ha az azon való adatokat hozzáférhetetlenné akarod tenni.
Az érdekes, amit írsz, hogy PCIe SSD-n a nagyobb sebesség miatt a procinak jobban kell nyomni a hash sebességet, és emiatt jobban leszívja az erőforrásokat. Ez igaz is lehet. Én csak SATA meghajtókon használtam eddig, ott lassulást, gyorsabb merülést nem lehetett mérni.
Esetleg ha céges üzleti noti, akkor az SSD oldalán lehet bekapcsolni a hardveres titkosítást, annak semmi köze a szoftveres szinthez, OS, proci felé transzparens. Viszont NVMe SSD-knél nem tudom mennyire lehetséges, melyik támogatja, mert amúgy ATA-jelszóval kell bekapcsolni, de az NVMe-nek semmi köze az ATA/SATA protokollhoz.
Ha mindenképp szoftveres titkosítást szeretnél, az rendszerköteten bonyolultabb, mivel gondoskodni kell a bootolhatóságról, és SSD-n még az is bonyolító tényező, hogy ha ATA/SATA SSD-ről van szó, akkor a TRIM parancsot is át kell engedni a szoftveres rétegen, NVMe-nél elvileg nem.
Amit írtam, példát paranccsokkal, azt csak nem rendszerlemezek titkosításához írtam, tipikusan HDD-hez.
-
drup
junior tag
válasz
Frawly
#64111
üzenetére
Csak most tudtam megkoszonni, hogy valaki irt vegre.
Koszonom, mindenkeppen kiprobalom.
A gepvetel nem az en asztalom, de ha az illetonek nincs penze egy kifuto win7-re, akkor nem lesz hajlando a tobbszoroset kolteni jobb gepre.
Az en dijazasom meg a retesek, az pedig - kulonosen szegfuszeggel es egyebekkel - eleg csabitoak, az esetenkenti sikitozas is belefer mellette, amig birom.Csak a pendrajvom elvesztese fajt, vegre volt egy nagy meretu a sok 2 meg 4 gb-os mellett, erre pillanatok alatt megdoglott.
Az infok pedig azok, amiket itt kerdeztem toletek hetek alatt, illetve azok alapjan weben kerestem es letoltottem kezikonyveket, koztuk szaz oldal feletti leirast shell parancsokrol es hasonlokrol, mert kozben tanulgattam, de most kezdhetem elolrol az egesz kutakodast.
-
drup
junior tag
válasz
CPT.Pirk
#64090
üzenetére
Mar a live is fekete kepernyon par soros hibauzenetek utan indult be, a telepito inditasa utan sokaig fekete a kepernyo, majd gyorsan vagy tucatnyi, vagy meg tobb sornyi hibauzenet jott, a tobbseg ERR!-akarmikkel kezdodott, de volt time out vagy over time vagy hasonlo szoveg, de mintha 4-5 szobol allt volna es alahuzasok lettek volna a szavak kozott, de az biztos, hogy azok nehany sor vegen voltak, nem volt idom megjegyezni es nem is volt jol olvashato. Mintha lett volna atomic szo is egy vagy ket sorban, mondat elejen levo szavak kozott. Nemcsak betuk, hanem furcsak karakterek is szerepeltek koztuk.
Majd a telepites elejen lealt, hogy nem sikerult a fajlok masolasa, es utana tobb oldalnyi hibauzenetet irt ki a kepernyore, mire elindult a leallasi folyamat.
Gondolom ez a szitu, amikor jo lenne egy speci program, ami rogziti a kepernyore irott szovegeket, de sajna ilyenem nincs, meg kamera se, es az angolom es a szemem se tul profi.Ja, ha ez segit, hasonlo tortent a live linux (?) 4.2 verziojaval is azzal a kulonbseggel, hogy ott mar a live se indult el. (nem emlekszem pontosan a nevere, csak a 4.2-re, a megdoglott pendrajvon volt, azt probaltam eloszor.)
-
válasz
Rimuru
#64133
üzenetére
Kossz! Es ha megvaltoztatom a root jelszot, akkor hozzaferek a titikositott kotetekhez?
Az lenne a celom, hogy megallapitsam, hogy a rendszer SSD titkositasat meg tudom-e uszni.Egy korabbi incidens utan az IT-sok mindent titkositottak a ceges laposon, de a PCI-E SSD-t tartalmazo laptopok eseten ez merheto uzemido csokkenessel jar. Nem veszes, de enelkul is sokat kell toltot keresni, nem jon jol meg ez is. Illetve tobb konkurens file muvelet eseten en lassabbnak is erzem a rendszer mukodeset (eleinte azt hittem, hogy csak belemegyarazom, de megmertuk egy UI automatizmus segitsegevel. (
) Olyan 15% korul van a lassulas ha egyszerre 5-6-nal tobb a file muveletek szama: alkalmazasok kinyitasa, becsukasa, git checkout, debug logolas bekapcsolva a lokalisan futo java webapp-on, 5 percenkeni email fogadas, lokalisan futo SQL query-k, stb.).
A SATA-s rendszermeghajtok eseten nem vettek eszre semmit a kollegak.
Szerintem - mivel a proci terhelesben nincs kulonbseg - az procinak van egy maximalis hash atviteli sebessege, ami sata-nal nem okoz limitet, de gyorsabb ssd-t mar visszafog. De ez csak kovetkeztetes, nem vagyok benne biztos.
Az en laposomban pci-e ssd van, igy megprobalom meguszni a titkositast. -
-
hódmaci
senior tag
Sziasztok!
Kis segítséget kérnék.
Volna egy pc-m amin linux mint 19 cinnamon fut
Szeretnék egy mappát megosztani (samba) windows10es pcknek.
viszont feltétellel kellene belépniük a megosztott mappá(k)ba.
Vagyis:Mindenkitől aki be akar lépni a megosztott mappába felhasználói nevet és jelszót kellene kérni és ez alapján eldönteni a jogosultságait.
pl.:
A1 és A2 pc belépés után csak olvasni tudja. Lehet ugyanaz a felh.+ jelszó
B1 és B2 pc belépés után olvasni és írni is tudja. Lehet ugyanaz a felh.+ jelszóFelhasználói név + jelszó nélkül nem lehet hozzáférni a megosztott mappá(k)hoz.
Remélem nem voltam bonyolult
kérte telepítsem a sambat ezt megtettem majd,
annyit sikerült elérnem, hogy megosszam. de csak úgy hogy bárki beléphet és azt tesz benne amit csak akar. -
-
válasz
CPT.Pirk
#64125
üzenetére
A vita abból állt, hogy mi lesz, ha nem adsz meg root felhasználó jelszót a Debian telepítőjében, és a telepítő így magától beállít sudo jogot a te felhasználódnak.
Ez nem vita tárgya, ott van képekkel alátámasztva. Amúgy pontosan én sem értettem mi a vita témája, csak azt tudom, hogy az előbbi kérdéssel lett tisztázva az, amikor a kérdező nem értette, miért nincs sudo-ja!? (nekem meg ugye mindig van, emiatt próbáltam segíteni a tisztázásban, mint lelketlen laikus)
Ez a cikket direkt nem linkeltem, mert annyira még innen sem pofoneccerű.....
-
#64126
cigam
titán
ArthurShelby
#64124
válasz
ArthurShelby
#64124
üzenetére
Réges rége, még az óperációs rendszeren is túl...
Az a lényege, hogy vagy van root, és akkor az első felhasználó _se_ kap jogot a sudo-zni, vagy nincs root(van csak disabled), és akkor van sudo az elsőnek létrehozott felhasználónak. Ami logikus is hiszen ha a root le van tiltva, csak kell legyen aki emelt szinten adhat ki parancsot.
Amúgy meg vihar a biliben, mert pár parancsal engedélyezhető a root, vagy adott user hozzácsapható a sudozni tudók táborához.
Na tessék beelőztek...
-
#64125
CPT.Pirk
Jómunkásember
ArthurShelby
#64124
CPT.Pirk
Jómunkásember
válasz
ArthurShelby
#64124
üzenetére
A sudo, vagyis magyarosan "szuper júzer tedd meg nekem" egy bevett dolog az "asztali" disztróknál.
Általában az van, hogy van egy root felhasználó, meg van a te felhasználód. Ha kell valami extra dolgot csinálnod, akkor a sudo-val meg tudod tenni, hogy azt a parancsot emelt jogokkal futtatod. Ez pl. azért jó, mert így véletlen elgépelt parancsok csak a te jogaiddal fognak futni, nem fogod csak úgy törölni magad alól a fájlrendszert.
Debian alatt egy picit manuálisabb a helyzet, mert ha megadsz jelszót a root felhasználónak, akkor a te felhasználód magától csak úgy nem kap sudo jogot, azt neked kell megadni neki, miután egyszer belépsz rootként. Ezt csinálja a a sudo adduser felhasználó sudo parancs, ami a felhasználót beteszi a sudo csoportba. A felhasználó ezt követően fogja tudni használni a sudo-t.
A vita abból állt, hogy mi lesz, ha nem adsz meg root felhasználó jelszót a Debian telepítőjében, és a telepítő így magától beállít sudo jogot a te felhasználódnak. A megoldás az, hogy semmi, mert inaktív lesz a root felhasználó fiókja.
-
-
válasz
Frawly
#64119
üzenetére
OK! Most az a pillanat is elérkezett, amikor Debian esetén tökéletesen ugyanazt írjuk!
van root jelszó - nincs sudo
nincs root jelszó - felhasználói jelszó van, quasi desktop disztróként viselkedik, mint az Ubuntu/Mint
Biztonsági kockázatról meg éppen tegnap esett szó.....root jelszó ide root jelszó oda!
Látom amott, hogy a jobbkormányos MX SSD-d is kezd kampeca lenni!
Naja, az sem egy Intel 520 -
Frawly
veterán
válasz
ubyegon2
#64118
üzenetére
Nem gabalyodtam be semmibe. Nem kap, ott írja, ha a root-nak adsz meg jelszót, akkor a többi felhasználónak nem lesz sudo-val rendszergazdai jog. Pedig az lenne a kívánatos, ha alapból lenne ilyenkor is. Sőt, én ezt oda szigorítanám, hogy ilyen telepítőknél nem is engedném, hogy ne legyen a root-nak jelszava, akkora biztonsági kockázat. A Debian meg ezzel a húzással csábít rá.
Abban igazad van, hogy Archon sem az van, aminek lennie kéne, sajnos. De ott könnyebben elnézi az ember, mivel annyira minimalista, hekkelős disztró, eleve nem kezdőknek, ezért ott nem okoz gondot.
-
válasz
Frawly
#64117
üzenetére
nem is téged akarlak támadni ezzel, de ez úgy ahogy van, f4xság. Kapásból biztonsági kockázat, ha a root-nak nincs jelszava.
Tudom, hogy nem engem piszkálsz ezzel, de amúgy tévedsz, a root-nak külön jelszava van, azt adod meg az imént illusztrált 1. képen, majd 3 képpel később adod meg a felhasználói jelszavad.
Ha nem adsz meg root jelszót, akkor ugyanúgy viselkedik a rendszer, mint Ubuntu/Mint esetén.
Gyakorlatilag Desktop Debian lesz belőle.desktop disztrókon az alapbeállításnak annak kéne lennie, hogy az összes korlátozott user kapjon sudo-val rendszergazdai jogot
Ez így is van, nem?
Belegabalyodtál ebbe az ARch-ba, mint majom a házicérnába!
-
Frawly
veterán
válasz
ubyegon2
#64114
üzenetére
Értem amit írsz, nem is téged akarlak támadni ezzel, de ez úgy ahogy van, f4xság. Kapásból biztonsági kockázat, ha a root-nak nincs jelszava. Bárki bemászik a rendszeredbe, csak bejelentkezik root-tal és tárulnak is fel előtte a kapuk.
Semmi köze a root jelszónak ahhoz, hogy egy másik felhasználónak milyen jogokat ad a sudo. Igazából a /etc/sudoers dönti el, hogy adott felhasználói csoportnak milyen sudo jogai vannak.
Egyébként rosszul emlékeztem, mert alapból Archon sem ad rendszergazdai jogokat a sudo, szerkeszteni kell hozzá a sudoers-t. De ez attól független, hogy adsz-e meg root jelszót vagy nem. Ezzel sem értek egyet, desktop disztrókon az alapbeállításnak annak kéne lennie, hogy az összes korlátozott user kapjon sudo-val rendszergazdai jogot, és ha valaki annyira le akar korlátozni egy felhasználót, akkor vegye el tőle utólag ezt a jogot.
-
válasz
sh4d0w
#64115
üzenetére
Igazad van, én láttam, hogy írtad. Sajnos Archereknek ezt így el kellett magyaráznom.
Én meg ezek miatt nem tartom kezdő disztrónak, az Ubuntu/Mint 8-10 telepítősegédes ablakához viszonyítva a Debian-nak még a GUI-s telepítősegédje sem annyira egyértelmű, még akár elolvasva az odaírtakat sem.Ezzel a mostani dologgal is az a gond, hogy hiába olvassa el egy kezdő, nem nagyon fogja érteni ezt a dupla jelszavazási metodikát, csak annyit lát, hogy itt meg kell adni a jelszót kétszer, az persze még jól összezavarja, hogy 3 ablakkal később szintén meg kell adni valami jelszót.
-
válasz
Frawly
#64110
üzenetére
Ezt én nem értem. A Debian miért kever ezzel.
Szerintem inkább roppant egyszerűvé teszi a választást, legalábbis grafikus felületen, ezt kár lenne összehasonlítani az Arch telepítési metodikájával.
"Adja meg a rendszergazda jelszavát (kétszer megerősítve). Mint az információs üzenetben szerepel, a "root" rendszergazdai fiók létrehozása nem kötelező. Ha üresen hagyja a mezőket, az első felhasználó megkapja az adminisztrációs feladatok teljesítéséhez szükséges jogokat a "sudo" paranccsal és a jelszavával."
Így már remélem érted, miről van szó.
Ha üresen hagyod a jelszavak helyét, akkor a következő ablakokban megadott felhasználó név egyszercsak egy ilyen ablakkal találja szemben magát, ahol már, mint egyszerű felhasználó adhatja meg a jelszavát. No ekkor tudja majd sudo-val használni a rendszert telepítés után. Ha az első ablakban megad jelszót, akkor nem tudja használni sudo-val a rendszert.
Ez kb olyan, mint az 1x1, szerintem!
-
Rimuru
veterán
válasz
Frawly
#64110
üzenetére
Arch-on úgy van ahogy beállítod, alaptelepítésnek nem része a sudo. Viszont ha még telepítéskor felrakod és beállítod simán tovább lehet lépni beállított root jelszó nélkül.
Amúgy aki nem tud róla hogy telepítette az valószínű base-devel csoporttal rakta fel és alap beállításon csak a root-nak működik, minden más csoportot/usert kézzel kell felvenni (a wheel-t is) -
Frawly
veterán
Ja, erre még válaszolok, ha újra nekifutnál. A meghajtónevet az lsblk paranccsal tudod megnézni. Ezt kell a dd-nek is megadni.
Egyébként ha egy ilyen nagyon régi laptopról van szó, akkor lehet nem éri meg a rá fordított idő. 30-50k között vannak refurb üzleti notik (i5-i7, 4-8 GB RAM szintje), amikre normálisan tudsz akár Win10-et, akár Linuxot telepíteni, mindenféle szenvedés nélkül, nem hal meg rajta semmi.
Azt sem értem, hogy milyen infókat írtál ki pendrive-ra. Letöltöd még egyszer a Mint 19 iso-ját, előveszel egy jó pendrive-ot, és kiírod arra egy jó gépről. A pendrive az ilyen, fogyóeszköz, a legtöbb ócska, minél olcsóbb fajta, annál hamarabb tönkremegy. Én azért is használok SSD-ket USB-SATA adapterrel, gyorsabbak és tartósabbak is, mint egy pendrive, és alig drágábbak. A telepítés is gyorsabb róluk.
Nekem egyébként a Rufus is kiírt még mindent sikerrel, igaz rég használtam. Nem értem a Mint 19-et miért ne tudná kiírni. Kiválasztod, hogy dd-s kiírás meg BIOS+MBR bootmode-hoz írja és meg kell tudnia csinálnia. Nincsen nagy trükk sehol. Kiírás előtt esetleg azt érdemes megnézni, hogy a letöltött Mint 19 iso-jának az SHA checksumja megegyezik-e a szerveren jelölttel, azaz a letöltés nem sérült-e.
-
Frawly
veterán
válasz
ubyegon2
#64084
üzenetére
Ezt én nem értem. A Debian miért kever ezzel. Én Archot is úgy használom, hogy van a root, annak van egy jelszava, akkor van az én felhasználóm, annak is van egy jelszava. A sudo mégis ad rendszergazdai jogokat a felhasználómnak.
Archon muszáj is a root-nak jelszót csinálni, különben az alaptelepítés után nem tudsz bejelentkezni, ha jól emlékszem. Bár ki tudja, lehet ki lehet trükközni, hogy más a telepítéskor chroot környezetben létrehozom a felhasználómat, és annak adok jelszót, de nem érné meg ez a hozavona, jó ha a root-nak is van jelszava.
-
drup
junior tag
Tudnam, hogy miert nem lehet soha az eletben egy nyugodt ev vegi pihenesem.
Hetek ota szenvedek ezzel a laptoppal, amikor vegre jonak tunt, kiderult, hogy megse az.
Ujra nekialltam, eloszor eltunt a pendrajvom az osszegyujtott infokkal es leirasokkal es a korabbi tappasztalatokkal egyutt.
Majd az ujratelepites okozott problemakat, ujabb tesztek.
Szepen kimentettem egy 16 gb-os pendrajvra a telepitoket es ismet lementett infokat, erre a pendrajv az elso dugasnal megdoglott.
Nagy nehezen ismet telepitettem a mint 17-et, erre a laptop kijelzoje elhalvanyul, mintha csak akkurol dolgozna, hiaba mondom neki, taprol megy, csak felhomalyos marad a kijelzo.
Piszokul faradt vagyok es piszokul elegem van az egeszbol. -
Nagy vonalakban: be lehet bootolni közvetlenül a shellbe root jogokkal a grub szerkesztésével indításkor.
Másik módszer, ha bootolod a gépet livecd-ről.
Azt érdemes tudni, hogy a lemeztitkosítás is csak akkor védi az adatokat, ha a kulcs nincs a memóriában. Tehát pl csinálsz egz veracryptes titkosított konténert és csak addig csatolod fel, amíg onnan olvasol, vagy oda írsz, aztán unmount.
-
Frawly
veterán
A dm-crypt csak a csomag neve. Valami köztes konténerréteg mindenképp kell, LUKS, VeraCrypt vagy hasonló konténerformátum, amibe titkosít. Ebből a LUKS a legajánlottabb.
Fogod a HDD-t, létrehozol rajta egyetlen darab partíciót, ami lefedi az egész HDD-t.
Majd rendszergazdai jogokkal terminált nyitsz (pl. su):
cryptsetup -v luksFormat --type luks2 /dev/sdakrámicsoda1
Ez titkosítja az egész partíciót, default paraméterekkel, ami AES256-XTS SHA256-hash, legalábbis Archon.cryptsetup open /dev/sdakármicsoda1 titkositott
mkfs.ext4 /dev/mapper/titkosítottEnnyi a titkosítás. Ha kézileg akarod felcsatolni, akkor így lehet:
cryptsetup open /dev/sdakármicsoda1 titkositott
mount /dev/mapper/titkositott /kivant/csatolasi/pont/mappajaHa már nem kell az eszköz, akkor:
umount /kivant/csatolasi/pont/mappaja
cryptsetup close titkositottNem muszáj kézileg csatolni, sok fájlkezelő és commander típusú progi meg tudja nyitni az így elállított titkosított partíciókat, bekérik hozzá a jelszót, te csak kattintasz a meghajtóra, kapsz egy ablakot, beírod a jelszót, minden más automatikusan megy, felcsatolódik a partíció, már ha jó jelszót adtál meg. Rossz jelszó esetén vagy újra jelszókérő ablak jelenik meg, vagy hibaüzenet.
Lehet automatizálni is, bootkor. A /etc/crypttab fájlba ez menjen:
titkositott /dev/sdakármicsoda1
(vagy)
titkositott UUID=partíció-uuid-je none luksA jelszó elég erős legyen, min. 20 karakter, minél változatosabb, lehetőleg kisbetű, nagybetű, egyéb írásjel, meg lehet fűszerezni ékezetes betűkkel is. Ezt garantáltan nem töri fel senki, még akkor sem, ha esetleg mégis csatlakoznál a CIA-hez. Se FBI, se NSA, se senki nem tud vele mit kezdeni, nem tudják feltörni. Egyedül a titkosszolgálatok lehetnek kivételek, de azok sem technikailag törik meg, azok téged törnek meg, ütnek addig cipóvá, amíg el nem árulod a jelszót.
Javasolni szokták még a legelső parancs elé, hogy futtass végig az egész HDD-n:
dd if=/dev/urandom of=/dev/akarmicsoda bs=20M
Ez csak azt a célt szolgálná, hogy a HDD-n előzőleg titkosítatlan tartalom lepucolódjon, és így nem látszik a különbség a titkosított és titkosítatlan részek között. Ez ellen van egy gyorsabb módszerem. Létrehozod és titkosítod a partíciót, úgy, ahogy írtam. Mikor kész van, telemásolod mindenféle adattal, amid csak van, felmásolsz rá, hogy elfogyjon a szabad hely rajta. Utána törölhetsz belőle, ami nem kell. Azért szoktam így, mert ez gyorsabb, a /dev/random és /dev/urandom végig dd-zése elcseszettül lassú, főleg ha valami nagyobb HDD-ről van szó, egyszerűen kín kivárni, mire végigszüttyögi, akár még 24 óránál is több lehet. -
kemotox
addikt
-
Dave™
nagyúr
A pontos sorrendre már nem emlékszem, de a lényeg, hogy rendszerbetoltes előtt megadsz egy plusz paramétert, újra bootolsz, akkor megint elkapkod betöltés előtt, ekkor már root vagy jelszó nélkül, felcsatolod a fájl rendszert, listázod a felhasználókat és átírod a jelszavát. Ha jól rémlik valahogy így volt kb.
Nem kell hozza semmi, ez a legdurvább.
bocsi, szinte vakon gépeltem a skandináv laptopbillentyűn....../etc/init![;]](http://cdn.rios.hu/dl/s/v1.gif)
Naja, az sem egy Intel 520
Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- ÁRCSÖKKENTÉS Lenovo ThinkPad P51s, P52s, T570, T580 eredeti Lenovo, belső akkumulátor eladó
- iKing.Hu - Apple iPhone 16 Pro Max - Desert Titanium - Új, kipróbált
- BESZÁMÍTÁS! Gigabyte B760M i7 12700K 16GB DDR4 512GB SSD RX 6700 XT 12GB Rampage SHIVA Enermax 750W
- Csere-Beszámítás! RTX Számítógép játékra! I5 13400F / 32GB DDR5 / RTX 4070 Super / 1TB SSD
- Bomba ár! Lenovo ThinkPad X250 - i5-5GEN I 8GB I 128GB SSD I 12,5" HD I Cam I W10 I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged