SSH heslo vs. klíč?

[hknmtt]

Viem ze je dnes velmi popularne pouzivat pre ssh spojenia rsa kluce, ale ono v podstate stale ide len o heslo. Tak ma zaujima, ci ma pouzitie hesla, ktore je ulozene v nejakom trezore(keepass), ma nejaku markantnu nevyhodu oproti ssh klucu?

[Reklama]

[RDa]

heslo se da bruteforcovat, klic nikoliv

heslo mas 1 k 1 uctu  VS klicu mas N k M uctum

klic muzes mit pod heslem (na strane klienta), coz je ekvivalent trezoru (tedy az na moznost vynuceneho smazani pri opakovanem pokusu a neodemceni)

[Zopper]

1) Heslo se posílá na vzdálený stroj, zná tvoje heslo v plaintextu. U klíče tvůj privátní klíč neopustí tvůj stroj, takže kompromitovaný vzdálený stroj by musel prolomit RSA nebo libovolnou jinou šifru, co si zvolíš.
2) Jak dlouhé je tvoje heslo? I pokud bude mít 100 znaků, bude pořád snazší ho bruteforcnout, než privátní klíč.
3) Můžeš mít jednodušší heslo pro sudo a lokální přístup, které se ti bude snadno psát, a přitom tím nekompromituješ vzdálený přístup.
4) Jestli máš víc vzdálených strojů a víc klientů, tak heslo buď máš všude stejné, nebo ho musíš řešit individuálně, řešit propagaci na klienty, a všichni klienti tím pádem znají všechno. U klíčů se prostě nakopíruje veřejný klíč, který má každý klient svůj.
5) Když to chceš mít joo secure, tak ten klíč měj s heslem, které máš v tom keepassu, a pak ani uniknutí privátního klíče ještě není okamžitě konec světa. Ale pokud ti něco sedělo ve stroji a ukradlo privátní klíč, tak ti to nejspíš udělalo i odposlech kláves, takže reálně to je stejně jedno.

[Petr Krčmář]

Souhlasím s kolegy, ještě přidám jednu praktickou věc: Pokud vám klient potřebuje dát přístup k novému prvku, musíte si nějak předat heslo, což je velmi citlivá operace. S veřejným klíčem se nic takového nedělá, já mám veřejné klíče k SSH na webu a klient je stáhne a hodí na disk. Není třeba po síti nic přenášet nebo diktovat heslo do telefonu.

Já osobně nikde na SSH hesla nepoužívám, mám to všude zakázané a používám výhradně klíče.

Kód: [Vybrat]

PasswordAuthentication no

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

NEsouhlastím s tvrzením o populárnosti . Nesoushlastím s  tvrzením dnes. Tazatele

1) zná v plaintextu

Záleží jestli myslíš hesla obecně nebo metodu "heslo v ssh"
1)myslím, že ani heslo se neposílá mezi stranami u SSH, ale se jim(+salt) podepíše seed od serveru  (heslo se posílá snad jenom u HTTP(S) formulářů  ), ale nevim, rád se nechám poučit, jestli se ho protistrana=server dozví. Legitimní protistrana nebo i fake protistrana. Ale jisté je, že pasivní poslouchatel heslo nedokáže odsposlechnout.

největší rozdíl mezi heslem a klíčem je "v způsobu použití lidmi"
druhý rozdíl v hesle vs klíč je:
-obvykle klíč je asymetrický=ty držíš soukromý+veřejný* a protistrany vždy veřejný (a je jedno, jestli použití je pro podpis nebo šifrování)
-heslo symetrický prvek (v tom základním filozofickém pohledu). Dá se to ale upgradovat, že při zadávání hesla  určování hesla si server uloží jeho hash a heslo si dál už nepamatuje. Pořád to ale není asymetrické

třetí rozdíl je v způsobu generování:
heslo je prostě slovo
klíč je ta asymetrická dvojice


* = to je takový "Sytaktický sugar", že soubor s soukromým klíčem(protože to je nějaká i když jednoduchá datová struktura, obsahující různý smetí navíc  třeba jméno, exponent, prvočísla p a q, komentář, datum) v sobě obsahuje i veřejný

[Reklama]

[Ivan Brezina]

Krome hesla a klice je jeste k dispozici kerberos ticket (popr ssh certifikat, ale k tomu neexistuje rozsirena infrastruktura).
Kerberos je imho jeste lepsi volba.

Klice jsou pouzitelne pouze na infrastrukture kde je mozne forwarovani klicu,
pokud vam to spravce zakaze a donuti vas ulozit si privatni klic na kazdy server, tak jsou klice k nicemu.

Yubikey umoznuje integraci se ssh-agentem, kdy je privatni klic ulozeny v tokenu, ze ktereho se "nikdy" nedostane.
Utocnik pak nemuze privatni klic zkopirovat ani kdyz by ziskal root-a na vasem laptopu.

[LolPhirae]

ale ono v podstate stale ide len o heslo

Tak určitě. 

[M_D]

Krome hesla a klice je jeste k dispozici kerberos ticket (popr ssh certifikat, ale k tomu neexistuje rozsirena infrastruktura).
Kerberos je imho jeste lepsi volba.

S tím Kerberosem (GSSAPI) souhlasím na úrovni jednoho subjektu/firmy - lezu na X serverů v rámci jedné řízené domény, tak je to hodně přijemné.
Pokud musím skákat po jednom/dvouch serverech u X jiných subjektů, tak ten SSH klíč je asi základ/standard.

On jde i ten SSH klíč nebo certifikát automatizovat třeba přes LDAP, ale je to už je to větší pakárna na údžbu. Jakási integrace je v kombinaci s SSSD, ale jde si to naskriptovat v sshd asi čímkoliv a jakkoliv s voláním AuthorizedKeysCommand / AuthorizedPrincipalsCommand.

[vcunat]

Pokud navíc máte klíč na HW tokenu (yubikey a jiné), tak nejde kopírovat a existuje pouze v tom jediném fyzickém tokenu.  (pokud ho máte, nemůže být ukradený nebo mít zapomenutou kopii někde jinde)

[Zopper]

NEsouhlastím s tvrzením o populárnosti . Nesoushlastím s  tvrzením dnes. Tazatele

1) zná v plaintextu

Záleží jestli myslíš hesla obecně nebo metodu "heslo v ssh"
1)myslím, že ani heslo se neposílá mezi stranami u SSH, ale se jim(+salt) podepíše seed od serveru  (heslo se posílá snad jenom u HTTP(S) formulářů  ), ale nevim, rád se nechám poučit, jestli se ho protistrana=server dozví. Legitimní protistrana nebo i fake protistrana. Ale jisté je, že pasivní poslouchatel heslo nedokáže odsposlechnout.

https://www.rfc-editor.org/rfc/rfc4252#section-8, upozorňuji zvláště na frázi "plaintext password". Žádné solení se tam nepopisuje, ssh client prostě pošle heslo, jak ho uživatel zadal.

[PCnity]

Pripajam sa k nazoru, ze password sa dostava do sshd v plaintexte a teda samotne sshd by ho mohlo dumpovat ak by chcelo. Ak to tak UZ nie je, prosim o info.

Cize NIE, kluc nie je len ina forma hesla.

[Exceptions]

Pripajam sa k nazoru, ze password sa dostava do sshd v plaintexte a teda samotne sshd by ho mohlo dumpovat ak by chcelo. Ak to tak UZ nie je, prosim o info.

Cize NIE, kluc nie je len ina forma hesla.

wireshart ti to poví . Putuje v plaintextu na vyzvání serveru. Před jeho odeslání proběhne kontrola host key jako obrana proti MitM, ale pořád to znamená, že tvoje heslo opustí tvoji stanici.

Logicky, pokud se heslo kontroluje proti /etc/shadow, tak těžko může putovat v nějaké odvozené formě, když klient neví jaký algoritmus je v shadow použit.

[PCnity]

Pripajam sa k nazoru, ze password sa dostava do sshd v plaintexte...

wireshart ti to poví . Putuje v plaintextu na vyzvání serveru.

Nuz to je ta infomracia s ktorou pracujem, mohol vsak nastat vyvoj o ktorom neviem a napriklad zamedzenie posielania hesla zo strany klienta by default.

Kym to tak NIE je, nemozme tvrdit ze by kluc bol len inou formou hesla. Ked k tomu pridame dalsi vyhody klucov, ako je napriklad bezpecna distribucia cez nezabezpeceny kanal, nie je o com. Za mna je odporucanie jasne, vypnut password login a nie len pre roota.

[k3dAR]

Viem ze je dnes velmi popularne pouzivat pre ssh spojenia rsa kluce, ale ono v podstate stale ide len o heslo. Tak ma zaujima, ci ma pouzitie hesla, ktore je ulozene v nejakom trezore(keepass), ma nejaku markantnu nevyhodu oproti ssh klucu?

ne dnes, je (alespon u me) "popularni" aspon 15let ;-) naopak uz minimalne par let neni "popularni" pouzivat RSA, ale ed25519 klice... v podstate me nenapada jiny rozumny duvod pro pouziti (a mit povolene) ssh heslo, nez na prvotni nahrani public casti klice pres ssh-copy-id ;-)

[Exceptions]

Viem ze je dnes velmi popularne pouzivat pre ssh spojenia rsa kluce, ale ono v podstate stale ide len o heslo. Tak ma zaujima, ci ma pouzitie hesla, ktore je ulozene v nejakom trezore(keepass), ma nejaku markantnu nevyhodu oproti ssh klucu?

ne dnes, je (alespon u me) "popularni" aspon 15let ;-) naopak uz minimalne par let neni "popularni" pouzivat RSA, ale ed25519 klice... v podstate me nenapada jiny rozumny duvod pro pouziti (a mit povolene) ssh heslo, nez na prvotni nahrani public casti klice pres ssh-copy-id ;-)

důvod proč používat heslo může být použití jiného backendu než shadow, např. ldap (přes např. pam) nebo kerberos. Pak lze kontrolovat různé pre-auth typu potvrzení na aplikaci či mít jiné komplexní kontroly, poslané heslo může být i OTP kód, protože už jsem autorizovaný třeba klíčem na nějakém bastion serveru.

Kdyby člověk chtěl, asi nějaké důvody najde. U klíče mi zase vadí, že nejsi schopný vynutit, že klíč je šifrovaný a že se třeba nepoužívá agent, tj. nastavit nějakou policy, jediná rozumná možnost je mít HW token, kde ten klíč. To mluvím hlavně o firemním prostředí.