Küsimus:
Miks on SSH-võtme kasutamine turvalisem kui paroolide kasutamine?
thequestionthequestion
2014-10-10 23:39:16 UTC
view on stackexchange narkive permalink

Kui inimesed kasutavad UNIX-i serverisse sisselogimiseks parooli, võib see olla sunnitud parooli aeguma, siis nad muudavad seda.

Kui inimesed kasutavad ssh-võtit ja neil pole paroole, parooli aegumist pole, siis ei sunni miski neid regulaarselt SSH-võtit vahetama.

Küsimus: milline lahendus on turvalisem? Miks soovitavad serveri karastamiseks mõeldud "juhised" alati kasutada ssh-võtit, mitte paroole?

UPDATE : kui arvestada toore jõu nõrkust - paroolide osas, sest neid võiks aimata, kui Fail2bani-laadset lahendust pole.

fail2ban pole hõbekuul. Nad kirjutavad omaenda [veebisaidil] (http://www.fail2ban.org/wiki/index.php/Main_Page): "Konfigureerige teenused kasutama ainult kahte tegurit või avaliku / privaatse autentimise mehhanismi, kui soovite tõesti teenuseid kaitsta. "
Ma arvan, et mõnda neist saab leevendada kahefaktorilise autentimise konfigureerimisega, kasutades libpam-google-authentator. See võib olla parem strateegia kui lihtsalt ühe neist 2 valimine.
Ma ei näe selle väärtust, kuid (serveri poolel) ei tohiks olla keeruline üles kroniteerida tööd, mis "aeguvad" võtmed failis `Author_keys`; või (kliendipool) klopitakse üles cron-töö, mis "aegub" võtmed (pannes klienti parooli muutma).
Üks asi, mida õppisin klahvide vastu armastama, on see, et teil võib olla erinevate seadmete (või inimeste jaoks) erinevad võtmed. See võimaldab teil iga seadme võtmed eraldi tühistada (volitatud_võtmetest eemaldada) (nt kui müüte või kaotate) ja saate sellega hakkama.
Seotud: [Hea tava sama ssh-võtmepaari kasutamiseks mitmel masinal] (https://unix.stackexchange.com/questions/27661/good-practice-to-use-same-ssh-keypair-on-multiple-machines) unix.SE 27661
Kui kontrollite serverit, nõudes perioodiliselt uue avaliku võtme esitamist ja seejärel pööramist oma .ssh kataloogis ja vana võtme kustutamise, võite oma kasutajad sundida oma SSH-võtmeid aeguma.
Kolm vastused:
gowenfawr
2014-10-11 00:03:52 UTC
view on stackexchange narkive permalink

Nii võtmetel kui ka paroolidel on oma plussid ja miinused. Põhjus, miks "howtos" jms SSH-võtit soovitavad, on see, et nende arvates on nende miinused vähem murettekitavad kui paroolide miinused.

SSH-võtmed on pikad ja keerukad, palju rohkem kui ükski parool võiks olla. Kuid nagu te ütlete, pole neil kehtivusaega ja nad istuvad kettal, kust neid saab varastada. Teiselt poolt ei edastata neid kaugsüsteemi (välja arvatud võtme edastamine, natch), millised paroolid peavad olema.

Paroolid on üldiselt etteaimatavalt vältimatult nõrgad. Ehkki tugevate paroolide olemasolu on võimalik, on ikka ja jälle näidatud, et inimesed kasutavad nõrku paroole ja neil on halb paroolipraktika ... lühikesed, lihtsad, sõnapõhised, lihtsad mustrid ("p @ ssw0rd!"), Kirjutage neid, kasutage neid mitmel saidil, lähtuge nende telefoninumbrist, laste sünnikuupäevast, oma nimest. Juhite tähelepanu sellele, et võtmed ei aegu, kuid miks aeguvad paroolid? Selle tagamiseks, et jõhker rünnak enne parooli asendamist vähem lõhkeks. See ei ole probleem, mis võtmeid mõjutab.

Ja kui halvad paroolid kõrvale jätta, on isegi "head" paroolid õigetes tingimustes toore jõu (võrgu- või võrguühenduseta) suhtes haavatavad. Need tuleb edastada teise süsteemi või mõnda muusse kohta, kus kasutaja võib ekslikult neid saata.

Tõendite kogum viitab tungivalt sellele, et paroolid on nõrgemad ja võtmed on tugevamad.

* ja nad istuvad kettal, kust neid saab varastada *. Saate ssh-võtmete jaoks määrata paroolid.
Nõus - mis naaseb parooli / parooli probleemi juurde :)
Üldse mitte. See, et keegi ei jõua kunagi serverisse, isegi mitte räsina. Keegi ei saa seda jõuliselt jõustada, kui tal pole juurdepääsu teie kettale. Kui ssh-l on paroolid, saavad kõik seda julmalt sundida. See pakub mõlema lähenemise eeliseid.
Vabandust, ma oleksin pidanud olema selgesõnaline - ":)" tähendas, et see naaseb [inimolemusse] (http://www.cbsnews.com/news/the-25-most-common-passwords-of-2013/ ) [parooliprobleem] (http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time) "
OK, see on probleem. Kui seda ei saadeta serverisse, ei saa te kontrollida top 5k paroolide loendit
Privaatne võti ei lahku kunagi omaniku arvutist isegi agendi edastamise korral. Sel juhul edastatakse port, mida kaugsüsteem saab kasutada kohaliku võtme kontrollimiseks, kuid tegelik kontroll on kohalik. Keegi kaugsüsteemis saab privaatse võtmega allkirjastada, kuid tegelikku privaatvõtit ei paljastata ainult agendi edastamise ajal.
Samuti, isegi kui see / oleks / jõuaks edasi, edastataks see üle loodud ja turvalise SSH-ühenduse.
@Shadur, pole muret edastamise pärast mitte edastamise etapp, vaid see, kas keskkast on usaldusväärne või mitte.
Kuidas on võimalik parooli jõuliselt sundida?Kas pole piiratud, mitu sisselogimiskatset saate teatud aja jooksul teha?
@KaareZ võrgus (nt SSH-protsessi kaudu) võib katseid piirata, kuid siiski langeda selliste asjade ohvriks nagu "1000 parema loendi nimekiri" jms.Võrguühenduseta rünnakud - näiteks kui keegi saab süsteemi varifaili koopia - ei ole sel viisil piiratud.Pidage meeles, et ründaja võib rikkis või valesti konfigureeritud teenuste kaudu saada failidest koopiaid, näiteks varju, kuid tal ei ole juurdepääsu kontole enne, kui ta suudab neid paroole jõuliselt sundida.Seevastu SSH-võtmetega pole olulist bitti üldse serveris.
Enamasti õige, kuid seal on väike viga: "miks paroolid aeguvad? Selle tagamiseks, et jõhker rünnak enne parooli asendamist vähem tõenäoline puruneks. See pole probleem, mis võtmeid mõjutab."Parooli aegumise peamine põhjus on kahjustuse peatamine, kui parooli on rikutud, ilma et keegi seda teaks.Parooli pööramine ei aeglusta jõhkrat rünnakut eriti.(Kui parooliruumi otsimiseks kulub 1 aasta, siis kui te ei roteeri, on mul 100% see, et saan selle aasta jooksul. Kuid kui vahetate iga 6 kuu tagant, on mul siiski võimalus saada neist üks 75%)
Klient või server võivad võtmed "aeguda", see võib olla sama lihtne kui "kui minu poole faili loomise kuupäev on vanem kui 6 kuud, kustutage see".Nii et ühendus ei toimi kuidagi, sundides teid looma uue paari või vähemalt taastama vana paari :)
Tom Leek
2014-10-11 00:32:30 UTC
view on stackexchange narkive permalink

Paroolidega saadetakse parool serverile, seega on parooli turvalisus seotud sellega, kui hästi server kaitseb kõike, mida ta paroolide kontrollimiseks kasutab (nt fail / etc / shadow ). SSH-võtme kasutamisel jääb teie privaatne võti kliendipoolele ja salajast väärtust ei saadeta kunagi serverisse. Isegi kui server on vaenuliku kontrolli all või kui teid kuidagi võltsserveriga ühendatakse, jääb teie SSH-võti turvaliseks. Võltserver ei saa teie võtme kohta piisavalt teavet selle taastamiseks või mõne MitM-i tegemiseks. Selles mõttes on SSH-võtmed serveripoolsete kompromisside vastu tugevamad kui paroolid.

Teiselt poolt tuleb SSH-võti salvestada kuhugi, arvutisse ja see võib olla haavatavus. Peate oma privaatvõtit kaitsma parooliga; vastasel juhul muutub varastatud sülearvuti konto kompromissiks. Seevastu parooli saab ajusse salvestada ainult , mis muudab selle väidetavalt lekkimise tõenäolisemaks.

Seega võib väita, et SSH-võtmed on "turvalisemad" "kui paroolid, kuid võib väita ka vastupidist. See sõltub kontekstist. Enamik HowTosid võtab seisukoha, et võtmed on paremad, sest juhtub nii, et keskmiselt on inimkasutajatel paroolide kohta kohutavad andmed. Kasutajad valivad nõrgad paroolid ja kasutavad neid uuesti (paroolide taaskasutamine on väga halb).

Mulle jäi mulje, et ssh-s olevad võtmed ja passid kaitsevad * serverit *. Väide, et võtmete kasutamine hoiab kliendi saladuse puutumatuna, tundub kummaline: kui server on juba ohustatud, siis mis on kliendi võtmete / passide saladuses hoidmise väärtus? (See jätab võltsserveri argumendi endiselt puutumatuks.) Ründaja saab juba rikutud serveris teha kõike, sealhulgas tagaukse installida.
SSH-s pole kliendivõtmed serveripõhised (tavaliselt). Antud kasutajal on _ üks_ avalik / privaatne võti paar ja ta kasutab seda mitme serveriga ühenduse loomiseks. Probleem, millest siin räägin, on see, kas ühe serveri rikkumine annab kaudselt juurdepääsu kõigile teistele serveritele, millega kasutajal on õigus ühendust luua - ja vastus on eitav, kuna kliendivõtmeid kasutatakse SSH-s.
Nagu [privaatsete / avalike võtmete taaskasutamine] (https://security.stackexchange.com/questions/10203/reusing-private-public-keys) turvalisus. SE/10203, näen. Täname puhastuse eest!
Shane Andrie
2014-10-11 01:28:30 UTC
view on stackexchange narkive permalink

Kui teie värskenduses saan aru, kas teie paroolides ja võtmetes on sama entroopia kui selle turvalisuse seisukohast on vaieldav. Võiksite öelda, et võtmed on paremad, sest see annaks parema "kasutuskogemuse", kuna te ei kirjuta paroole iga kord.

Ma arvan, et rohkem kui teie algne mõte, arutleme SSH-i hallatavuse üle paroolid vs SSH-võtmed. Jah, paroolidele saab määrata poliitika, mis lubab põhilisi turvameetmeid (IE parooli aegumine, parooliajalugu, parooli maksimaalne pikkus jne), kuid see ei muuda inimese harjumust ega rõõmusta ka kasutajaid, kus turvalisus muutub koormavaks tootmine (Tasakaal organisatsiooni tasandil).

Klahvid pakuvad meetodit teatud entroopia ja juhitavuse säilitamiseks, pakkudes samas ka juurdepääsu meetodit, mis ei koorma kasutajat (kui teie võtmepaari seadistamine saab autentida ilma paroolita, kuni see tühistatakse.)

Lisaks teadke, et võtmeid saab parooliga kaitsta ja pakkuda teist kihti.

Tundub, et arvate, et võtmega sama entroopia paroolil on sama võti, kuid see on vale paroolist hoolimata, hoolimata sellest, kui kaua edastatakse ikka kaugserverisse, kus võtit pole. Looge parooliga ühendus petturitega ja see varastatakse, looge ühendus võtmega ja petturitest server ei saa sellega midagi peale hakata.
Tegelikult ei edasta kõik paroolisüsteemid võtit võrgu kaudu. Näiteks Kerberos seda ei tee: selle asemel saadetakse kõigile, kes väidavad, et nad on kasutajad, pilet, kuid pilet krüpteeritakse kõigepealt kasutaja parooliga. Nii et see tuleb kliendi poolel dekrüpteerida, enne kui see on millekski kasulik, ja selleks peab parool olema õige. Selle saavutamiseks peate kogu aeg parooli võrgu kaudu saatma. Teiselt poolt tähendab see, et teil peab olema üks masin, mis salvestab kõik paroolid selge tekstiga, nii et masin tuleb * kõvasti lukustada.
@TheSpooniest Kerberos [ei pea selget teksti parooli salvestama] (http://security.stackexchange.com/questions/15849/does-the-kerberos-kdc-know-the-users-plaintext-passwords) KDC-s; see krüpteerib pileti mitte kasutaja parooliga, vaid millegagi, mis on tuletatud kasutaja paroolist, eelistatavalt ühesuunalise funktsiooniga. Selle rikkumine kahjustab Kerberose valdkonna kontosid (tuletatud võti on kõik, mida ründaja peab autentima), kuid ei lase ründajal iseseisvate teenuste ründamiseks kasutada rikutud paroole, kui kompromiteerida "/ etc / shadow".


ⓘ
See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...