-
GAMEPOD.hu
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
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.
[ Szerkesztve ]
-
kemotox
addikt
-
anorche1
őstag
Egyszer probakent a manjarot ugy telepitette, hogy a particionalaskor bekapcsoltam a luks titkositast.
Ezt be lehet kapcsolni valahogy ujra particionalas/telepits nelkul is, mukodo rendszeren?"It never gets easier, you just go faster." Greg LeMond
-
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. -
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.
https://www.coreinfinity.tech
-
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. -
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.
-
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.
-
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)Vigyázat, csalok!
-
nagyúr
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!
[ Szerkesztve ]
-
-
nagyúr
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.
[ Szerkesztve ]
-
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.
-
nagyúr
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!
[ Szerkesztve ]
-
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.
-
nagyúr
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
[ Szerkesztve ]
-
Frawly
veterán
-
-
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.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
cigam
félisten
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...
[ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
nagyúr
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ű.....
[ Szerkesztve ]
-
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.[ Szerkesztve ]
Hölgyeim! Azt tesszük a kirakatba ami eladó.:)
-
félisten
válasz Frawly #64106 üzenetére
Koszi a leirast, hetvegen megcsinalom.
(#64102) Dave™ es (#64107) sh4d0w : Koszi nektek is a valaszokat!
Ezzel kapcsolatban meg annyit kerdeznek, hogy ha ilyen modszerekkel bebootolok a rendszerbe, akkor meg tudom nezni valahogy a root vagy user jelszot, vagy csak megvaltoztatni tudom?
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
félisten
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.[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
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.)
[ Szerkesztve ]
-
-
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.
-
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.
[ Szerkesztve ]
-
félisten
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?
[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
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..
-
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.
-
nagyúr
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.
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
-
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)
Vigyázat, csalok!
-
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.
-
félisten
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.Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
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?
[ Szerkesztve ]
Hölgyeim! Azt tesszük a kirakatba ami eladó.:)
-
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.
Új hozzászólás Aktív témák
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!
- Microsoft licencek a KIVÉTELES ÁRAK - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Eredeti Windows, telepítéssel! Digital Doctor Számítógép Szerviz
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."