Fórum Root.cz
Hlavní témata => Server => Téma založeno: hknmtt 17. 03. 2025, 14:01:12
-
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?
-
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)
-
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.
-
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.
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ářů ;D ), 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ý
-
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.
-
ale ono v podstate stale ide len o heslo
Tak určitě. ::) ;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.
-
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)
-
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ářů ;D ), 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.
-
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.
-
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.
-
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.
-
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 ;-)
-
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í.
-
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í.
Tohle je asi nejzásadnější nevýhoda ověřování pomocí klíčů a je to asi taky ten hlavní důvod proč ho některé firmy nechtějí používat.
-
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í.
Tohle je asi nejzásadnější nevýhoda ověřování pomocí klíčů a je to asi taky ten hlavní důvod proč ho některé firmy nechtějí používat.
Pokud mají kontrolu nad strojem, můžou ssh-agent zablokovat. A generovat sadu klíčů na serveru a nedovolit uživatelům si nahrávat vlastní. Ale tak jako tak, co mi přesně brání si udělat ssh_company.sh, který prostě udělá něco stylem echo "username\npassword" | ssh? :) To jsou ty snahy o zvýšenou bezpečnost, které vedou ke žlutým papírkům s heslem nalepeným na monitoru a pracovním čase spáleném bojem mezi IT a zaměstnanci.
-
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í.
Tohle je asi nejzásadnější nevýhoda ověřování pomocí klíčů a je to asi taky ten hlavní důvod proč ho některé firmy nechtějí používat.
Pokud mají kontrolu nad strojem, můžou ssh-agent zablokovat. A generovat sadu klíčů na serveru a nedovolit uživatelům si nahrávat vlastní. Ale tak jako tak, co mi přesně brání si udělat ssh_company.sh, který prostě udělá něco stylem echo "username\npassword" | ssh? :) To jsou ty snahy o zvýšenou bezpečnost, které vedou ke žlutým papírkům s heslem nalepeným na monitoru a pracovním čase spáleném bojem mezi IT a zaměstnanci.
vygeneruješ šifrovaný klíč, ale už nezajistíš, že si ho uživatel nedešifruje a nebude mít v plaintextu. Jak se blokuje ssh-agent, když si uživatel může do socketu v env SSH_AUTH_SOCK dát jakoukoliv aplikaci (jo jasně, můžeš to nějak hardcodovat, vyměnit ssh klienta za vlastního atd.), to ale pořád znamená, že ta policy se vynucuje velmi obtížně.
Pokud to heslo bude OTP kód z aplikace, to echo ti moc nepomůže.
Tobě to připadá jako nesmyslný boj, já zase zažil až příliš ukradených ssh klíčů, protože si je nějaký program přečetl z home složky uživatele a donutit uživatele, aby spustit pod sebou na linuxu nějaký program (i blbý pip install) je dneska strašně snadné nebo když se kdejaká věc instaluje přes curl https://... | bash.
Ten linux to prostě nemá dobře vyřešené, dá se to nějak předělat, ale to znamená to extra vymyslet pro každou distribuci a pravidelně to aktualizovat. Nejsem zastánce přepisování kódů nebo neustálému zadávání master hesla pro každé ssh sezení.
-
vygeneruješ šifrovaný klíč, ale už nezajistíš, že si ho uživatel nedešifruje a nebude mít v plaintextu. Jak se blokuje ssh-agent, když si uživatel může do socketu v env SSH_AUTH_SOCK dát jakoukoliv aplikaci (jo jasně, můžeš to nějak hardcodovat, vyměnit ssh klienta za vlastního atd.), to ale pořád znamená, že ta policy se vynucuje velmi obtížně.
Pokud to heslo bude OTP kód z aplikace, to echo ti moc nepomůže.
Tobě to připadá jako nesmyslný boj, já zase zažil až příliš ukradených ssh klíčů, protože si je nějaký program přečetl z home složky uživatele a donutit uživatele, aby spustit pod sebou na linuxu nějaký program (i blbý pip install) je dneska strašně snadné nebo když se kdejaká věc instaluje přes curl https://... | bash.
Ten linux to prostě nemá dobře vyřešené, dá se to nějak předělat, ale to znamená to extra vymyslet pro každou distribuci a pravidelně to aktualizovat. Nejsem zastánce přepisování kódů nebo neustálému zadávání master hesla pro každé ssh sezení.
Tahle opatření jsou dost zvláštní. Pokud bych chtěl zajistit větší bezpečnost, dám uživatelům tokeny a klíče budou na nich. Pokud někdo nechce, aby měl uživatel na disku klíč bez hesla, a musel by to kontrolovat, nevadí mu, že hned vedle toho klíče s heslem může mít uložený textový soubor, kde to heslo bude napsané? Ano, předejde to plošnému útoku, který bude jen sbírat soubory id_rsa, ale tomu předejde i prosté přejmenování toho souboru…
-
vygeneruješ šifrovaný klíč, ale už nezajistíš, že si ho uživatel nedešifruje a nebude mít v plaintextu. Jak se blokuje ssh-agent, když si uživatel může do socketu v env SSH_AUTH_SOCK dát jakoukoliv aplikaci (jo jasně, můžeš to nějak hardcodovat, vyměnit ssh klienta za vlastního atd.), to ale pořád znamená, že ta policy se vynucuje velmi obtížně.
Pokud to heslo bude OTP kód z aplikace, to echo ti moc nepomůže.
Tobě to připadá jako nesmyslný boj, já zase zažil až příliš ukradených ssh klíčů, protože si je nějaký program přečetl z home složky uživatele a donutit uživatele, aby spustit pod sebou na linuxu nějaký program (i blbý pip install) je dneska strašně snadné nebo když se kdejaká věc instaluje přes curl https://... | bash.
Ten linux to prostě nemá dobře vyřešené, dá se to nějak předělat, ale to znamená to extra vymyslet pro každou distribuci a pravidelně to aktualizovat. Nejsem zastánce přepisování kódů nebo neustálému zadávání master hesla pro každé ssh sezení.
Tahle opatření jsou dost zvláštní. Pokud bych chtěl zajistit větší bezpečnost, dám uživatelům tokeny a klíče budou na nich. Pokud někdo nechce, aby měl uživatel na disku klíč bez hesla, a musel by to kontrolovat, nevadí mu, že hned vedle toho klíče s heslem může mít uložený textový soubor, kde to heslo bude napsané? Ano, předejde to plošnému útoku, který bude jen sbírat soubory id_rsa, ale tomu předejde i prosté přejmenování toho souboru…
Security through obscurity, prostě ten klíč schovám jinám :-D
HW tokeny jsou super, ale ne vždy to lze nebo je vůle na koupit, bohužel. Je tady spousta dalších cest, třeba ssh klíče je možné podepisovat certifikátem s krátkou platností a tím omezit případný dopad v případě úniku, je možné použít auditovací nástroj a monitorovat přístup ke klíči jiným procesem než ssh atd. atd.
Tohle byla jen ukázka, že klíč je super, ale chce myslet na to, že sám o sobě nemusí stačit a objeví se nové problémy.