SSH a bezpečnost hesel

[BD]

Zdravím, do nedávna jsem pro přihlašování přes SSH vyžadoval pro všechny uživatele používání klíčů. Poslední dobou mne lidé kamenují ze všech stran tak jsem se rozhodl, že budu mít jen jednoho uživatele, který bude mít možnost commandu "su". Tento uživatel jako jediný musí používat pro přohlášení klíč, ostatní ne.

Mám klid z řad userů ale nedá mi spát pár nastavení okolo bezpečnosti. Když se všichni uživatelé museli přihlašovat pomocí klíčů, měl jsem nastavené

Kód: [Vybrat]

ChallengeResponseAuthentication
UsePAM
jako "no".

Jak by jste mi doporučili nastavit výše zmíněné funkce v případě, že je přihlášení na server umožněno i pomocí hesel? Když mám oboje jako "yes" tak se přihlášení pomocí klíče dá obejít. Pokud mám ChallengeResponseAuthentication no a UsePAM yes tak přihlášení dělá trošku neplechu, např zobrazí dvakrát MOTD. Takže momentálně moje nastavení vypadá:

Kód: [Vybrat]

PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM no

Match Group secure-ssh-login
 PasswordAuthentication no

Tohle nastavení dělá asi nejmenší neplechu, zda-li je bezpečné si nejsem jist.

Podle dokumentace a rad blogerů jsem prostě nenašel takové vysvětlení, které by mi tuhle problematiku 100% objasnilo.
Díky moc všem za rady.

[Reklama]

[JardaP .]

A co kdyz toho jednoho usera, ktery smi su, budete pouzivat pouze na pripojeni pres ssh a nastavite mu pekne vypecene heslo, treba maximalni mozne delky nahodnych znaku? Pak at si to prihlasovani pres klice nekdo obchazi, kdyz na to ma nekolik miliar let.

[h7]

Tak tak, hlavní výhodou klíče z pohledu bezpečnosti je to, že je automaticky generovaný a dlouhý. Pokud se povolí hesla, tak si uživatelé volí často různá slovníková apod., které se dobře lámou. Ale to neznamená, že dobře vytvořené heslo je méně bezpečné.

(samozřejmě výhody jsou i další - třeba nemuset mít pro každý server jiné heslo apod.)

[OMG]

to je jako kdyz prijde zakaznik do autopujcovny a chce auto bez brzd, protoze on pry nebrzdi...
Kdyz Vas uzivatele pozadaji o moznost mit 1 znakove heslo, prestavite server aby to podporoval? Misto prestaveni serveru vysvetlete manazmentu proc jsou klice nutne a proc zadne hesla nebudete na SSH podporovat a pokud ziskate podporu manazmentu, pak to vysvetlete i uzivatelum. Nebo dejte tady ip kde mate to SSH s prihlasovanim heslem a rano tam mate par novych uzivatelu. 
Zbytecne si zadelavate na dalsi a dalsi zbytecnou praci...

[OMG]

jeste mozna blby dotaz, ale ti uzivatele pouzivali po prihlaseni "su"? Rika Vam neco "sudo"? Pokud se chcete ptat na SSH a obecne bezpecnost, pak se nekde doctete ze uzivatel by mel mit moznost delat jenom to co musi. Treba mu omezite sudo na restart aplikace nebo co potrebuje, ale davat "su" uzivatelum je blbost.

[Reklama]

[Tomáš Crhonek]

Hlavně je třeba si uvědomit, že přihlašování heslem a přihlašování pomocí klíčů jsou dva zcela odlišné mechanismy, které nelze moc srovnávat.

Zatímco při přihlašování heslem se posílá ono heslo po zabezpečeném kanále (který se před tím musí nějak pomocí DH vytvořit), předá se pam a to potom dle záznamu v shadow (nebo třeba ldapu) ono heslo (ne)přímo porovná (posolená hash - jak moc dobrá je ta funkce? není prolomená jako md5 nebo skoro prolomená sha1?), tak při přihlašování pomocí klíčů se nic neposílá, pouze si pomocí asymetrické kryptografie obě strany vymění klíč pro další symetricky šifrovanou komunikaci.

Tedy dost dobře nelze nahradit klíč heslem, byť by měl stejnou entropii, a myslet si, že je to totéž. Není. Otisk hesla musí být někde uložen v nějaké podobě a potom se s ním něco porovnává. Zatímco klíče patří ke kompletně jinému principu asymetrické kryptografie.

Nehledě na to, že 24 znakové heslo o dostatečné entropii (112b) si stejně asi nikdo nezapamatuje, tak silnější 4kb RSA klíč může mít třeba na čipovce (takže si nic pamatovat nemusí, maximálně 112b passfrázi).

[JardaP .]

@Tomáš Crhonek: Tedy s tim prolomenim md5 to neni tak horke. To, ze lze jaksi pracne sesmolit koizi, je mi uplne na hovno, kdyz se nedostanu k shadow, abych tam ukradl hash. Zejmena by mne zajimalo, jak se hodlate k shadow dosapat pres ssh, kdyz ani neznate heslo.

[Daniel]

jeste mozna blby dotaz, ale ti uzivatele pouzivali po prihlaseni "su"? Rika Vam neco "sudo"? Pokud se chcete ptat na SSH a obecne bezpecnost, pak se nekde doctete ze uzivatel by mel mit moznost delat jenom to co musi. Treba mu omezite sudo na restart aplikace nebo co potrebuje, ale davat "su" uzivatelum je blbost.

Mozna jste mne spatne pochopil. Uzivatele samozrejme nemuzou pouzivat "su". To muze jen jeden uzovatel administrator a to jsem ja. Ostatni uzivatele jsou chrootnuti do home folder a maji vyhraze prava pres "sudo". Nejsem blazen.

Docela dobre vas vsechny chapu. Vite jak to chodi pokud pracujete v IT. Ja jsem jen obycenjny radovy Network administrator, ktery ma na spravu Linuxove servery (nestesti, ktere na mne spadlo po kolegovi).
Pokud se na mne vrhne deset lidi, ze proste zadne klice nebudou pouzivat, pak jsem zahnany v rohu. Chci maximalni zabezpeceni serveru ale musi byt v ramci toho, kolik firma chce investovat. To je ten hlavni problem. Radoby hlavouny moc nezajimaji kecy o bezpecnosti, vi o tom prd, jedine co umi je pocitat prachy.

Vseobecne se tedy jeste zeptam, kdyz odpoved na mou otazku jsem z vas nedosta.

Bud prihlasovani klicema nebo heslama. Ale nekombinovat. Chapu vas spravne?

Popripade, pokud pouziji kommbinaci obojiho, je nasleduji konfigurace spravne z ohledu bezpecnosti?

1 user - administrator muze pouzivat "su" ale loguje se jen pouzitim klice.
other users pouzivaji hesla, predem generovana min. 120 bitova.

Konfigurace:

Kód: [Vybrat]

PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM no

Match Group secure-ssh-login
 PasswordAuthentication no

Moc dekuji tomu, kdo mi potvrdi nebo vyvrati bezpecnost vyse zmineho nastaveni.

[Filip Jirsák]

Já si myslím, že to nastavení je bezpečné. Ale nevím, jak byste to chtěl potvrdit. Předpokládám, že jste zkoušel přihlásit se pod tím uživatelem bez klíče a že se vám to nepodařilo. Případně můžete zkusit spustit ssh s parameterem třeba -vvv a podívat se, jak se serverem komunikuje a co server nabízí. Když tomu uživateli navíc nastavíte opravdu silné heslo (nebudete ho používat, takže klidně 30 náhodných znaků), nemáte se podle mne v tomto směru čeho bát.
Spíš se ale divím té vzpouře uživatelů proti klíčům. Zrovna dneska jsem rozkopírovával svůj klíč na šest nových serverů, protože by mne asi brzo odvezli do blázince, kdybych měl to heslo zadávat pořád dokola. Co se na tom uživatelům nelíbí? Není problém jenom v tom, že klíče neumějí používat? Že nevědí, že si použitím klíčů velmi zjednoduší život?

[Jenda]

Nastavit uživateli jako heslo `cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c 30` mi přijde dobrý nápad. Možná také jde do passwd/shadow napsat nesmyslný hash nebo hvězdičku.

Co se na tom uživatelům nelíbí? Není problém jenom v tom, že klíče neumějí používat? Že nevědí, že si použitím klíčů velmi zjednoduší život?

Mí uživatelé se chtějí přihlašovat z více počítačů a nejsou schopní si buď klíč rozkopírovat, nebo si přidat na server klíče ze všech počítačů. Na Windows s PuTTy je to o něco větší pakárna než na Linuxu. A oni se přihlašují jednou denně, ne jako já, kterej furt někam leze a spouští hromadu scp a navíc mají heslo qwertz, tak je to zadávání neotravuje.

[mca]

Muzes vymyslet ruzne metody, ale nakonec stejne skoncis u hw reseni, ktere minimalizuje naroky uzivatele a podstatne zvysuje uroven bezpecnosti na prijatelnou uroven (Gestapo nechme spat). TPM chipy jsou dnes vsude, klavesnice a smartky se daji poridit vcelku levne. Cilem je potlacit selhavajici lidsky faktor, ktery kasle na zasady a prevenci - v tom je i jnak tripismenkov deravy hw stale lepsi.

[M.]

Varianta, že RSA/DSA klíč používá fakticky jen admin a normální uživatele heslo je v podstatě dost běžná. Zvláště pokud se ti uživatelé hlásí převážně z LAN a podobné. Pro zpříjemnění ještě více, pokud lidi třeba sedí u svých notebooků s windows (které jsou v AD doméně, ať už Windows server nebo Samba4) a používají putty  a i ty linux servery patří k firmě dané domény, tak zvážit nastavit Kerberos přihlašování. Pak to mají ještě příjemnější, než s klíči.
Provozuje plně Kerberizované prostředí a mezi uživateli vládne naprostá pohoda. A další bud bude získávání ticketů dle příhlášení čipovou kartou, tak pak ještě větší pohoda...

[Filip Jirsák]

Na Windows s PuTTy je to o něco větší pakárna než na Linuxu.

Vždyť stačí zkopírovat jeden soubor a nastavit spuštění agenta s příslušným klíčem po nastartování systému... Případně pokud spouští jediný příkaz, můžou mít na ploše rovnou odkaz na plink s příslušnými parametry, jenom na to kliknou a nemusí zadávat vůbec nic.

navíc mají heslo qwertz, tak je to zadávání neotravuje.

Server je tedy bezpečně dostupný jen z LAN, a víte, že v LAN žádný útočník být nemůže? Resp. že když se na server přihlásí kdokoli z LAN, nevadí to?