ssh kulcs auth miert jobb?

Lehet, hoyg a forumba kellene...Mindegy. Igazabol arra lennek kivancsi, itt a hupon sokan hasznalnak key auth-ot ssh-ra, pass helyett. Miert jobb? Tenyleg jobb?
- elonyok: nem kell megjegyezni, keylogger nem tudja ellopni
- hatranyok: egy adathordozon ott kell lennie, tehat keylogger sem kell, hoyg barmilyen program elcsipje a filet. Ha elhagyod az adathordozot (pl. pendrive) ment a levesbe. Igaz, ki kell talalni, hova szol a key.

Szoval? Miert is jobb, mint a pass?

Oke, de egy eros jelszo sztem meg jobb.
Epp azon gondolkodtam, ha magyar szavakbol all a jelszavad, akkor a bruteforce-nak sokkal kisebb az eselye (pontosabban a szivarvanytablas bf-nek), bar a "kurva" pl. lengyel hackerek ellen nem ved :)

Ha eleg hosszu jelszot hazsnalsz, akkor a bruteforce belathato idon belul nem valosithato meg.

Mittomen "TokajSzollovesszeinNektartCsepegtettel", ezt nem hiszem, hogy mostanabn feltorik.
Viszont nem kell fileban tartanom.

--
http://www.micros~1

Igen, csereben egy csomo hibalehetoseg van:
- Csendben valamiert nem magyar kiosztas van alattad (ez foleg az ekezetek miatt lehet zavaro, de a z/y problema is komoly lehet)
- Eleg hosszu, nagyon konnyu elfelejteni

Egy kulcsnal az ember vigyaz, mert ahogy a szemelyi igazolvanyt vagy a lakaskulcsat se hagyja el az ember napi szinten, ugy az ssh kulcsat se.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Felreerted, nem azzal van a gond, hogy az ember ne tudna a Himnuszt. Hanem azzal, hogy "melyik sora?" "Ezen a gepen a Himnusz vagy a Szozat elso sora a jelszo?" es ezek nem ismerete ugyanazt az eredmenyt adja: nem tudsz belepni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( sj | 2013. 04. 06., szo – 00:23 )

egyreszt a kulcsnak is lehet jelszava, masfelol az ssh szerveren levo publikus kulcsban pl. definialni lehet, honnan lehessen hasznalni. Szoval jo az a kulcs, szeressuk, mert igy nem eleg a "valamit ismerni", hanem kell a belepeshez a "valamit birtokolni" is.

Diktatorok kezikonyve

Oke, en latom, hogy sokan szeretik, de ettol meg nem ertem, miert joBB, mint a jelszo.
Honnan: ezt lehet tuzfalrol is szabalyozni.

birtoklassal az a gondom, hogy elveszhet. Honnan szedem ujra elo? Vagy megsemmisul az adathordozo.

Titkositas: tarolhatom a kulcsot pl. Truecrypt particion is, addig ved, amig nincs mountolva.
Ha beszedtem egy spy programot, akkor nem ved, amint mountolom, el tudja olvasni.

Igaz, beszedhetek keyloggert is, akkor meg a jelszot lopjak el.

Szoval meg mindig nem latom be, hogy annyival jobb lenne, mint a jelszo. Nem azert kerdeztem, mert nem hiszem el, hoyg jo, csak azt nem ertem, mivel jobb.

Mondjuk, kulcs+jelszo mar oke.

--
http://www.micros~1

Hát kulcsot jelszó nélkül generálni mindennél a legrosszabb. Az olyan mintha plain text-ben tárolnád a jelszavadat.

Tehát szerintem erős jelszóval védett kulcsnak van értelme - és azért jobb mint a jelszó, mert:
- lehet sok kulcsod ugyanazzal a jelszóval védve, tehát a külön szervereidnek külön kulcsa lehet, mégis mivel ugyanazzal a jelszóval véded a kulcsot, így elég egyetlen jelszót tudnod fejből, de ha hozzáfértek egyik host-odhoz, a többihez attól még nem biztos
- a kulcs maga egy erős jelszó mindenfajta trükközések nélkül (magyar szó vagy mnemonikok stb), véletlen mintánál nincs erősebb
- ha erős a jelszavad, azt is fel kell jegyezned valahová, legalábbis érdemes - ugyanez kulcsnál, tehát backup mindig kell - ettől nem rosszabb a kulcs szerintem
- megoszthatsz mással is hozzáférést ugyanazon a hoston ugyanahhoz a felhasználóhoz anélkül, hogy a jelszavadat meg kellene osztanod a másikkal (ugye itt a /home/user/.ssh/authorized_keys fájlba több publikus kulcs párt is betehetsz)

"Hát kulcsot jelszó nélkül generálni mindennél a legrosszabb. Az olyan mintha plain text-ben tárolnád a jelszavadat.
Tehát szerintem erős jelszóval védett kulcsnak van értelme - és azért jobb mint a jelszó, mert:"

Koszi, ez igy mar egesz mas. Tehat amikor itt a HUP-on a kulcsos azonositast emlegetik, akkor voltakeppen jelszoval vedett kulcsrol van szo. Igy mar azert egesz mas es tenyleg sokkal biztonsagosabb (ket, kulonbozo elven mukodo zar mindig biztosabb, mint barmelyik egyedul)

--
http://www.micros~1

Csak abban az esetben, ha a user nem gyengiti. Azaz csinalathatok en a userrel kulcsot akarmilyen passphrase-zel, ha o aztan leszedi rola azt. Akkor mar tobbet er a jelszo alapesetben.
Ha viszont megtehetem, h megbizok a userben, akkor tobbet er a jelszavas kulcs.
A jelszo viszont csak addig OK, amig azt le nem tarolja plaintextben (akar a Desktop\jelszo.txt-ben, akar a winscp-ben elmentve).

Ezen a szinten nincs jo megoldas, csak ha a user is akarja es tesz erte.

tompos

Hát nem, több okból is kifolyólag.
1: A papírt le lehet másolni a smart card-ban generált privát kulcsot nem! Más szóval a jelszó (kulcs) időben és térben egyszerre csak egy helyen lehet
2: A smart card védhető jelszóval 3-5 próbálkozás és a kártya kéri a PUK kódot-> még 10 próbálkozás és blokkol a kártya-> kuka!

Abban viszont, közös, hogy ha elveszted akkor nem tudsz belépni. (De kártya esetén -hacsak nem írtad fel a PIN-t mellé egy papírra- más sem.)

"A smart card védhető jelszóval 3-5 próbálkozás és a kártya kéri a PUK kódot-> még 10 próbálkozás és blokkol a kártya-> kuka!"
Azaz rakunk a jelszóra még egy réteget, egy jelszót. A problémát ugyanúgy nem oldja meg, csak több infóval kell rendelkezni ugyanahhoz a dologhoz. Ez olyan, mintha az eredeti jelszóbekérés után egy újabb jelszót kérünk be, hogy végül bejussunk a rendszerbe.
Ezzel csak a jelszavak száma növekedett meg.
"A papírt le lehet másolni a smart card-ban generált privát kulcsot nem!"
http://www.cl.cam.ac.uk/~osc22/docs/smartcards.pdf

"Azaz rakunk a jelszóra még egy réteget, egy jelszót. A problémát ugyanúgy nem oldja meg, csak több infóval kell rendelkezni ugyanahhoz a dologhoz. Ez olyan, mintha az eredeti jelszóbekérés után egy újabb jelszót kérünk be, hogy végül bejussunk a rendszerbe."

Ez majdnem ekvivalens a ssh-s privát kulcs + jelszó annyi különbséggel, hogy a brute-force ellen védve vagyunk.

"A papírt le lehet másolni a smart card-ban generált privát kulcsot nem!"
Pontatlan voltam, a fenti megállapításom az ún. BALE eszközökre vonatkozik. (Azokból tényleg nem lehet kiszedni semmit.) ["sima" SMART CARD != "BALE" SMART CARD]

( dong0 v | 2013. 04. 06., szo – 12:22 )

Nem kell semmi felhasználói interakció az ssh használathoz. Ez egy elég komoly előny, ha scriptekben használod.

( blajo | 2013. 04. 06., szo – 14:37 )

Egy par dolog meg, ami eddig nem volt elegge hangsulyozva:
- authorized_keys-ben eleg aprolekosan meg tudod mondani, mit csinalhat egy kulcs birtokosa (konkret parancs, forwardok, tty allokalas ilyesmi)
- Kenyelmes: ssh-agent hasznalataval egyszer megadod a sajat gepeden a kulcs jelszavat, es barhova tudsz menni (erdemes timeout-ra, vagy xlock-ra torolni a kulcsot a memoriabol)
- Biztonsag: agent-forwardot meg senki nem emlegette: csak a sajat geped memoriajaban van a privat kulcs. Ha hasznalsz ugrodeszka gepet valamiert, ami nem biztonsagos, akkor a jelszavadnak annyi; mig a privat kulcsod a sajat gepeden biztonsagban van. (Itt is vannak finomsagok: maga a privat kulcs valoban nem kerul ki a gepedrol; de ha tovabblepsz egy masik gepre, akkor az adott kapcsolat tamadhato; sot meg akar az agent is.)

( asch v | 2013. 04. 07., v – 01:29 )

A helyi géped ha nem biztonságos, akkor tetszőleges authentikációs protokoll sem lesz biztonságos, ebből a szempontból elméleti különbség nincsen, és nem is lehet. A különbség a szerver oldali törések lehetőségeiben van.

Jelszavas authentikáció esetén a szerver, amire bejelentkezel el tudja lopni a jelszavadat. Ezért minden helyen, ahol accountod van, elvileg külön jelszót kellene használnod. Szerintem ezt fejben kb lehetetlen menedzselni.

És akkor még nem beszéltünk arról, hogy hiába van nem életbevágó helyekre külön jelszavad, mert simán el tudod rontani beírásnál. Például tegyük fel, hogy be akarsz lépni a "helyilegjobbpizza.org" weboldalra, ahol még titkosítás sincsen a weboldalon de véletlenül reflexből a "master" passwordödet írod be a gyenge jelszavad helyett. Ez - elméleti szempontból legalábbis - olyan, mintha kiposztoltad volna facebookra. Ilyen hibákat pedig vétünk, mert nem vagyunk tökéletesek.

Az ssh authentikáció során a szerver - amin authentikálod magad - nem ismeri meg a privát kulcsodat, hanem csak bizonyítod, hogy ismered. A publikus kulcsod ismeretében a szerver a bizonyításodat ellenőrizni tudja, de a szerver nem kap olyan információt, amivel téged perszonalizálni tudna. ( Lásd: http://en.wikipedia.org/wiki/Public-key_cryptography ) Tehát használhatod ugyanazt a publikus/privát kulcs párt az összes helyen, ahova be kell tudnod jelentkezni. Nem kell minden oldalhoz külön "jelszó" ahhoz, hogy a biztonságodat legalább elméleti szinten megtartsd.

Érdemes megemlíteni, hogy az ssh authentikáció - amit a kulcsos belépéskor használunk - ugyanaz az algoritmus, amit a szerverek is használnak önmaguk authentikálására. A ~/.ssh/known_hosts fájlban az általunk ismert szerverek publikus kulcsai vannak, illetve a https-hez tartozó certificate-ek is ezt tartalmazzák.

Az általad említett másik probléma - nevezetesen hogy a számítógépen minden program hozzáfér az összes fájlodhoz, így a kulcsfájlhoz is - véleményem szerint egy fundamentális tervezési hiba a mai informatikában, de a jelszó/kulcsfájl problémakörtől elméleti szempontból ortogonális kérdés.

( hrgy84 | 2013. 04. 07., v – 13:14 )

A kulcsos authentikacio azert jo, mert nem kell jelszavadnak lenni egy gephez ahhoz, hogy hozzaferesed legyen. Mit jelent ez a gyakorlatban:
Adott egy nepszeru Git hosting, mondjuk a GitHub. Tekintve, hogy egy felhasznalo addig keptelen belepni a gepre, amig nincs neki _valamilyen_ jelszava, tehat a hostinghoz hasznalt 'git' felhasznalonak van egy 32 karakteres random jelszava. Viszont ez a jelszo fix.

Kepzeljuk el egy pillanatra, hogy a rendszer ugy mukodik, hogy mindenkivel megosztjuk a git felhasznalo jelszavat. 3 problema merul fel rogton:
- Mivel a jelszo folyamatosan fix, es lehet tudni, hogy van valami jelszo, sot, suttogo pletykak alapjan meg az is kideritheto, hogy 32 karakteres, ezert elobb-utobb a jelszo feltoretik, hiszen nem lehet tobbmillio felhasznalonal egyszerre jelszot valtani
- A jelszavas authentikacio SSH oldali problemaja, hogy a belepo userek nem valnak megkulonboztethetove. Nem tudom, hogy Celtic vagy hrgy84 lepett-e be. Ennekokan keptelen vagyok authorizalni az egyes repositorykhoz torteno hozzaferest
- Ennel is problemasabb azonban maganak a jelszonak a kompromittalodasanak esemenye. Egy adott felhasznaloszam felett (ez olyan 100 es 1000 fo kozott mozog) egyszeruen ertekelhetetlenul kicsi lesz annak az eselye, hogy a jelszo nem kompromittalodik.

Ezzel szemben a kulcsos authentikacional:
- A jelszo ugyanannal a usernel sem fix.
- Egy kompromittalodott kulcsot anelkul lehet eltavolitani a rendszerbol, hogy a tobbi parmillio felhasznalo egyaltalan tudna rola
- Mivel a kulcs egyben authorizal is, igy egy kulcs kompromittalodas valojaban joval veszelytelenebb, mint egy jelszo kompromittalodas.

Az SSH kulcs authorizaciora torteno felhasznalasa valojaban azonban implementacio kerdese. Lehetseges olyan authorized_keys fajlt irni, ahol elore megmondjuk, hogy belepeskor egeszen pontosan milyen parancs lovodjon fel a felhasznalonak a shell helyett. Ez lehet akar egy shell wrapper is, ahol megnezzuk, hogy az adott usernek mit kell felloni, vagy lehet egy Git/SVN szerver, barmi. A felhasznalo identifikalasa a kulcs altal triggerelt parancs argumentumainak befolyasolasaval tortenik. Tehat peldaul a: 


command="/usr/local/bin/gitsh hron84" ssh-rsa ... hron@merlin

beallitas mar elve egy olyan gitsh -t lo fel, aminek elpasszolasara kerul a 'hron84' felhasznalonev, mely alapjan lehetoseg nyilik a felhasznalo authorizalasara - attol fuggetlenul, hogy o valojaban a 'git' felhasznaloval lepett be.
Lehetoseg van arra is, hogy tobb kulcs tartozzon ugyanahhoz a felhasznalohoz, es az is lehetseges, hogy egy kulcs tobb felhasznalohoz is tartozzon. Ebbol az elsot nehez megvalositani jelszavas authentikacioval.

Persze felmerulhet kerdeskent, hogy az miert nem jo megoldas, ha minden usernek sajat accountja van. Nos...
- Egy UNIX rendszerben egyszerre csak korulbelul 65530 felhasznalo lehet. A tobbi altalaban rendszer user, root, nobody, stb. De csak 65535 nagysagu az UID ter, a tobbi mar implementaciofuggo.
- A felhasznalomenedzsment iszonyu bonyolultta valik. Ha meg akarok osztani valakivel valamit, ahhoz nem eleg egyet tikkelnem valahol, hanem csoportot kell letrehoznom, a csoporttulajdonost le kell valtanom, a csoport membereeket managelni kell, stb. Raadasul nyugos, ha _ket_ csoporttal kell valamit megosztani (igen, tudom, extended ACL, de ettol meg nyugos).

Osszefoglalva: az SSH kulcs nem csak a biztonsagrol szol, pontosabban nem csak egyszeruen levaltja a jelszot, mint authentikacios tokent, de plusz biztonsagot is tud hozzaadni a rendszerhez, illetve egy csomo funkcionalitas implementalasara is lehetoseget ad, melyre a korabbi felhasznalonev/jelszo alapu rendszer nem, vagy csak nehezkesen nyujt lehetoseget.

Azonban az SSH kulcs sem mindenhato. Az OTP jelszavak valamivel jobbak mint az SSH kulcs, hiszen folyamatosan valtozo tokent biztositanak minden belepeshez, amit sem keyloggerrel, sem az aldozat gepenek feltoresevel nem lehet megszerezni, cserebe az ezt biztosito fizikai eszkoz (token, mobiltelefon, tablet, etc.) eltulajdonitasa azonnali kompromittalodast jelent. Az SSH kulcs eseteben a kulcs maga vedheto jelszoval, igy eltulajdonitasa meg nem jelent azonnali kompromittalodast.

En ugy gondolom, hogy nincs "abszolut biztonsagos" authentikacios mod. A vedett objektum titkossaga donti el, hogy hogyan vedelmezzuk. Kis erteku dolgokhoz eleg lehet a jelszo is, kicsit komolyabbakhoz mar erdemes lehet OTP jelszot hasznalni, nagyon komolyan vedendo cuccokhoz pedig valamilyen tanusitvany alapu vedelmet erdemes bevetni (SSH public/private key, SSL cert/key), ami ennel is ertekesebb, ott pedig a biometriai azonositas is szoba jon. Esetleg barmelyik ketto kombinacioja.

De ez sokmindentol fugg. Lehet, hogy egyszerubb a OTP azonositas bevezetese, mert olyan a felhasznalobazis, hogy kicsi az eselye az eszkoz kompromittalodasanak. Van, ahol - ahogy az SSH eseteben - a tanusitvany alapu vedelem kepes extra biztonsagi faktort adni a rendszerhez. Van, ahol a biometria hasznalhatatlan, mert tul sok hozzaferest kell menedzselni, vagy egyszeruen nincs ido az azonositasra, esetleg elfogadhatatlan az alkalmazott eszkozok hibaszazaleka.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( Nyosigomboc v | 2013. 04. 07., v – 17:19 )

Neha jo a jelszo nelkuli kulcs is.
Pl. egy ismerosnek neha kellett segitenem tavolrol, de nem akartam kinyitni a gepen semmilyen portot. Az otthoni gepemen viszont beengedtem az ssh-t, es egy uj felhasznaloval (aki semmit nem tudott csinalni, mert nem kapott shellt) ki tudtam huzni tunnelt scriptbol, es azon vissza tudtam menni.
Akkor is lehet jo a passphrase nelkuli kulcs, ha a kulcsot egyeb modon mar kelloen veded (mondjuk titkositott particion van, es az adott felhasznalashoz ez mar kelloen biztonsagos).

--
The programmers of tomorrow are the wizards of the future. You know, you're going to look like you have magic powers compared to everybody else. -Gabe Newell