OpenSSH - bezpečně a pohodlně

21. 8. 2007 | Pavel Šimerda | Bezpečnost | 16129×

Prakticky všichni unixoví administrátoři a pokročilejší uživatelé znají a používají Secure Shell. Nejrozšířenější implementací je OpenSSH, která velmi dobře spolupracuje se zbytkem systému. Podíváme se společně na to, jak ho udržet bezpečné, aniž by nám překáželo v práci.

OpenSSH je od začátku vyvíjeno v rámci projektu OpenBSD a jeho zdrojové kódy jsou zveřejněny pod BSD licencí. Distribuce obsahuje SSH server, SSH klienta a přidružené programy.

Jako u většiny bezpečnostního softwaru, závisí bezpečnost především na způsobu používání. Je proto třeba pečlivě vyvažovat bezpečnost a pohodlí nebo najít způsob, jak skloubit obojí.

Ověření klíče serveru

Dříve, než začnete pracovat na vzdáleném počítači nebo mu pošlete heslo, byste měli vědět, jestli se opravdu připojujete na správný server a ne na nějaký cizí stroj. K tomu slouží klíč SSH serveru (SSH host key).

Klient si udržuje seznam serverů a jejich veřejných klíčů. Pokud se spojíte s jiným serverem, klient to ohlásí a odmítne se připojit. Jediným slabým bodem je v tomto případě první přihlášení, kdy ještě server v seznamu není. V takovém případě OpenSSH zobrazí otisk (fingerprint) klíče uživateli, aby ho mohl zkontrolovat. Na serveru zjistíte otisky klíčů serveru příkazem ssh-keygen.

(server)$ ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key
(server)$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Pokud spravujete server, který z nějakého důvodu nemá SSH klíč, musíte ho nechat vygenerovat (mně se vygenerovaly při prvním spuštění serveru). Můžete vygenerovat DSA klíč i RSA klíč.

(server)$ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
(server)$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''

Nabízí se otázka, co dělat, když administrátor z nějakého důvodu klíč serveru změní. Stačí nechat vymazat záznam o serveru, znovu se přihlásit, zkontrolovat otisk a nechat klienta, ať si přidá nový veřejný klíč.

(klient)$ ssh-keygen -R example.net
(klient)$ ssh uzivatel@example.net

Autentizace uživatele

Nejzákladnější metodou autentizace uživatele je zadání hesla (to se posílá až po ověření totožnosti serveru). Pokud máte pro každou službu nebo server vymyšlené bezpečné heslo, může se vám stát, že těch hesel bude příliš mnoho a nebudete si je všechny pamatovat. V horším případě začnete používat jedno heslo pro větší množství služeb, což může ohrozit bezpečné ověření vás jako uživatele.

Zajímavější alternativou je autentizace veřejným klíčem (public key authentication). V takovém případě stačí, aby server znal veřejný klíč uživatele. Veřejný klíč se vytváří příkazem ssh-keygen. Pro jednoduchost můžete vybrat DSA klíč. Pro bezpečnější práci je vhodné chránit (šifrovat) klíč nějakou bezpečnou passphrase (program se na ni zeptá).

(klient)$ ssh-keygen -t dsa

Kdybyste chtěli někdy změnit passphrase, opět pomůže příkaz ssh-keygen.

(klient)$ ssh-keygen -p -t dsa

Na každý server, kam se chcete touto metodou přihlašovat, zkopírujte svůj veřejný klíč. Přidejte ho do souboru .ssh/authorized_keys ve svém domácím adresáři na serveru. V sekci o SSH agentovi se dozvíte o elegantnějším způsobu přidávání veřejných klíču na server.

(server)$ cat id_dsa.pub >> ~/.ssh/authorized_keys

V tuhle chvíli se můžete přihlašovat bez zadávání hesla. Místo hesla ke vzdálenému počítači teď zadáváte passphrase vašeho klíče.

Na první pohled se toho moc nezměnilo, ale od této chvíle už neposíláte žádné heslo po síti. Pomocí passphrase se pouze rozšifruje klíč před použitím. To znamená, že můžete jeden klíč (s jednou passphrase) bezpečně používat pro přihlašování na mnoho serverů.

Bezpečnost autentizace veřejným klíčem spočívá v tom, že na straně serveru je uložený pouze veřejný klíč. Ten se dá použít pouze k ověření vaší totožnosti, pokud vy máte k dispozici svůj soukromý klíč (ověření serveru funguje podobně). To je velká výhoda oproti heslu, které musí být (v nějaké formě) uložené na serveru. Pokud chcete vědět více, přečtěte si něco o asymetrickém šifrování (viz odkazy a zdroje).

Používání klíčů usnadňuje i komunikaci s administrátorem, který vám zakládá účet pro vzdálený přístup. Nemusí vymýšlet žádné dočasné heslo, které byste si stejně změnili. Stačí, když mu dáte svůj veřejný klíč (nebo má možnost si ho najít).

SSH agent - více pohodlí

Abyste nemuseli zadávat passphrase při každém použití SSH, je tu pro vás program ssh-agent. Nejdřív je potřeba zařídit, aby se agent spouštěl a ukončoval, když se přihlásíte nebo odhlásíte.

(klient)$ echo eval \`ssh-agent\` >> .bash_login
(klient)$ echo eval \`ssh-agent -k\` >> .bash_logout

Po odhlášení a opětovném přihlášení by měl agent běžet. Můžete mu přidat svůj klíč pomocí ssh-add (bude po vás chtít zadat passphrase).

(klient)$ ssh-add

Rozšifrovaný klíč je teď uložený v paměti a připravený k použití. Do odhlášení nebudete muset passphrase zadávat. Navíc teď už můžete provést slibované elegantnější přidání veřejného klíče na server. Místo ssh spusťte ssh-copy-id. Příští přihlášení pomocí ssh už by mělo proběhnout bez zadávání hesla.

(klient)$ ssh-copy-id uzivatel@example.net
(klient)$ ssh uzivatel@example.net

pam_ssh – jedno heslo stačí

Pokud se vám nelíbí, že musíte po každém přihlášení ještě spouštět ssh-add a zadávat passphrase, potěším vás. Existuje modul pam_ssh pro PAM (Pluggable Authentication Modules, systém pro autentizaci uživatele), který umožňuje rozšířit přihlašování do systému o zavedení SSH agenta a přidání SSH klíče. K tomu, abyste tuto službu nastavili, samozřejmě potřebujete administrátorský účet.

Předpokládám, že balíček pam_ssh už jste si nainstalovali. V /etc/pam.d najdete konfigurační soubor služby (například xdm), u které chcete k přihlašování přidat podporu SSH agenta, a upravíte ho.

Nejdříve je potřeba přidat autentizaci pomocí pam_ssh a nastavit klasickou (pam_unix), aby v případě potřeby použila již zadané heslo (parametr try_first_pass). Pokud tento parametr vynecháte, bude se vás v případě neúspěchu systém ptát na vaše unixové heslo zvlášť.

auth     required   /lib/security/pam_env.so
auth     sufficient /lib/security/pam_ssh.so
auth     sufficient /lib/security/pam_unix.so try_first_pass likeauth nullok
auth     required   /lib/security/pam_deny.so

Pak se ještě hodí zavést pam_ssh session, která zajistí spuštění a ukončení SSH agenta. Pokud vám SSH agenta do teď spouštěl a ukončoval nějaký skript (například .bash_login a .bash_logout), nezapomeňte příslušné řádky zrušit.

session  required   /lib/security/pam_limits.so
session  sufficient /lib/security/pam_ssh.so
session  required   /lib/security/pam_unix.so

Po dokončení této konfigurace se můžete začít přihlašovat do systému svou ssh passphrase. Po přihlášení máte automaticky spuštěného agenta a zavedený klíč. Pořád vám samozřejmě zůstává možnost přihlásit se starým heslem (bez načtení SSH klíče).

Příště

Příště se odpoutáme od bezpečnosti a podíváme se, co nám může SSH nabídnout kromě očekávaného bezpečného připojení ke vzdálenému shellu. Dotazy a připomínky jsou vítány.

       

Komentáře

[MiK[3]Zz]

Od clanku som ocakaval trosku viac, no nevadi, zaciatocnikovi iste pomoze ako narabat s klucami.

Nastava dalsia otazka: ci je bezpecnesjsie pouzivat kluce alebo hesla? Tak ci tak sa nieco posiela cez siet, ci je to uz kluc alebo heslo a dekodovany kluc samozrejme, kedze passphrase sa zadava este na stroji, z ktoreho sa pripojuje. Dalsia zalezitost je ta, ze pokial uzivatel nepouziva passphrase a niekto sa fyzicky dostane k pocitaci, na ktorom je kluc, tak to takisto moze zneuzit (pokial by pouzival heslo, tak nemoze!).

[Semo]

Sama voda.

Kluc sa po sieti neposiela, ani zasifrovany. Iba verejny kluc servera, pokial nie je uz cachovany. Ak uzivatel nepouziva passphrase, tak rovnako mozeme predpokladat, ze si hesla uklada v plaintext subore alebo podobne hovadiny, ktore nic nehovoria o bezpecnosti SSH ale iba o debilite niektorych uzivatelov.

[MiK[3]Zz]

Urcite si niekto uklada hesla v plaintexte, tak to snad vravi za vsetko. Asi tym padom nechapete ako to funguje. Ci posielate heslo alebo kluc, je to to iste, stale idu informacie cez siet, inak by sa uzivatel nepripojil, keby nie. Je to relativne, co je bezpecnejsie.

[jm]

Vidim, ze jsi stale nepochopil, jak to funguje... No nic, nech to konovi, ten ma vetsi hlavu.

[MiK[3]Zz]

A to som ani nevravel o tom, ked v sshd zakazete prihlasovat sa heslom a budete nuteni prihlasit sa z neznameho prostredia, kde proste ten kluc nie je.

[jiri.b]

OTP - google vi :P

[jiri.b]

to mi pripomina... co zminit pouzitelnost ruznych java apletu - ssh clientu? jeden byl docela pouzitelny a free.

http://www.ece.osu.edu/ssh/

[pavlix]

OTP se chystám vyzkoušet.... a pokud se mi to zalíbí, možná o tom i něco sepíšu.

[Petr_N]

proboha, zadny klic se nikam neposila.

[moira]

Ale to heslo prece neni v plaintextu. To uz pak muzete argumentovat tim, ze veskery dalsi provoz SSH jde taky po siti a tim padem je to nebezpecne. A klic se neprenasi vubec (pokud to funguje, jak si myslim, ze to funguje).

[Filip Jirsák]

Ale vy klíč nikam neposíláte. Asymetrické šifrování funguje právě na tom principu, že máte veřejný a soukromý klíč. Co zašifrujete jedním, rozšifrujete druhým, a jediné, co je nutné někam "posílat" je veřejný klíč. V případě SSH se ten veřejný klíč "posílá" tak, že jej předem přiřadí na cílovém počítači administrátor k příslušnému účtu. Při přihlášení se pak tedy soukromý klíč nikam neposílá, pouze se jím na počítači, ze kterého se připojujete, něco zašifruje (nebo odšifruje).

[!]

Ale vy klíč nikam neposíláte.

co je nutné někam "posílat" je veřejný klíč.

udelejte si poradek v terminilogii a pak se treba budete schopni dohodnout?

[Michal Vyskočil]

Stručný popis principu najdeš v SSH receptem na bezpečnost 2. Důležité je, že klíč po síti neputuje, ale používá se kryptograficky bezpečné ověřování pomocí asymetrického šifrování.

[!]

Iba verejny kluc servera, pokial nie je uz cachovany

a jak by asi ssh poznalo, ze se se host key zmenil, kdyz zobrazuje upozorneni?

[Semo]

Ako to robi presne v reale to neviem, ale na to aby spoznalo zmenu by stacilo posielat hash. Alebo by mohlo rovno na blind nieco dostat/poslat o com sa vie, co ma z toho vyjst. A ak to nevyjde, tak sa kluc zmenil.

[BH]

Pekne pekne. Ani nevie o com toci, ale hlavne ze toci. Vsak Mikezz )

[MiK[3]Zz]

Iste, ze viem, mozno som to zle sformuloval, nebezpecie je tu vzdy.

[valy]

Nechceš-li se dále strapňovat, přečti si příručku asymetrického šifrování pro ÚPLNÉ ZAČÁTEČNÍKY

[MiK[3]Zz]

Tak strapnujes sa akurat tak ty. To je vsetko, co k tomu dodam dementko, ak si nepochopil o com pisem, tak sa k tomu radsej ani nevyjadruj.

[Semo]

Zneuznanemu geniovi tecu nervy?

[Filip Jirsák]

A můžete nám to tedy ještě jednou vysvětlit? Asymetrické šifrování se u SSH používá tak, že mám na serveru veřejný klíč, na klientovi soukromý. Server pošle výzvu, klient ji zašifruje soukromým klíčem, server rozšifruje veřejným a porovná s tím, co odeslal. Po síti se tedy pošle výzva a zašifrovaná výzva. Můžete nám v tomto kontextu vysvětlit, co říkají vaše příspěvky?

[jiri.b]

http://www.krypta.cz/articles.php?ID=132

[MiK[3]Zz]

Vyjadroval som sa skor k tomu, ze ak nie sme na svojom pocitaci, z ktoreho sa zvycajne pripajame na iny, tak nam asi kluce nebudu na nic platne, ba dokonca, ak zakazeme autentifikaciu heslom, tak sa na server vobec nepripojime, potom som spominal to, ze je to tiez nebezpecne, lebo sa kluce uchovavaju na tom pocitaci, cize ak sa niekto fyzicky dostane k pocitaci, tak moze zneuzit kluc, ak nepouziva passphrase a ak aj hej, tak je to otazka casu prist nan. Ak tu niekto pisal, ze to je blbost, lebo kto by nepouzival passphrase, ostatne ini si pisu hesla do plaintextu, tak nech sa trosku zamysli nad tym co vlastne napisal. Uznavam, ze som sa nevyjadril dostatocne jasne, doslo k par omylom, beriem spat, ze sa kluce posielaju cez siet. S dodatkom, ze po sieti sa pri autentifikacii heslom posiela zakodovane, takze je nepravdepodobne, ze by to niekto rozsifroval.

[jiri.b]

proste blablabla...

[MiK[3]Zz]

Vazne som necakal takuto inteligentnu odpoved, ale to asi svedci o tebe...

[jm]

Vazne som necakal takuto inteligentnu odpoved

Blablabla blebleble... jeste dlouho se tady hodlas ztrapnovat totalnim nepochopenim principu?

[Filip Jirsák]

Klíče nejsou závislé na počítači, můžu je nosit s sebou klidně na flash disku. Takže se můžu přihlásit i z cizího PC. A přihlašování z cizího PC je úplně stejné riziko s heslem jako s klíčem – počítač může odposlechnout jak heslo, tak heslo ke klíči.

Soukromý klíč ale také můžete mít uložený na čipové kartě, která jej nikam nebude kopírovat, ale bude sama provádět šifrování. S tím se pak můžete přihlašovat bez rizika i z cizího počítače – takovéhleho stupně bezpečnosti s heslem nikdy nedosáhnete.

Navíc keyloggery asi budou rozšířenější, než programy na krádeže soukromých klíčů, útoky přes slabá hesla asi budou častější, než útoky pokoušející se generovat náhodně soukromé klíče. Takže teoretické možnosti prolomení jsou možná stejné, ale prakticky je použití klíčů bezpečnější.

[jiri.b]

a proto OneTimePasswords :)

[pavlix]

Spíš bych doporučil klíčenku než flashdisk... je to trošku dražší... ale zase to klíč tomu cizímu počítači nevydá.

Alternativně One Time Passwords.

[pavlix]

Je mi líto, ale pro až takové začátečníky jsem to nenapsal... odkazy na vysvětlení asymetrického šifrování se mi bohužel redakčně ztratily, ale google funguje pořád.

Klíče vs. hesla Krátká odpověď: klíče a hesla

Privátní/soukromé klíče jsou od toho, že se po síti neposílají (což už slovo "soukromé" trochu naznačuje).

Pokud uživatel nepoužívá passphrase, je to jeho chyba (jeho věc, v některých případech se hodí mít i nešifrovaný klíč pro skripty).

pokial by pouzival heslo, tak nemoze!

Nahraď slovo "heslo" slovem "passphrase" a máš vyřešeno. Navíc můžeš bezpečně používat stejnou passphrase pro klíč, kterým se přihlašuješ k mnoha počítačům.

[jiri.b]

pro dalsi dily:

- ssh -w
- .ssh/config - HashKnownHosts
- .ssh/config - LocalCommand, SendEnv
- /etc/ssh/sshd_config - ForceCommand, Match # s tim se daji delat kouzla ;)

ad .bash_login & ssh-agent, no... neni to kvapek mateni ctenare? uz vidim jak si kazdy pepa dela .bash_login, kdyz treba ma .profile :) jednodussi by bylo napsat do konfiguracnich souboru vaseho shellu - man bash/ksh...

celkove ta sekce s ssh-agentem je takove rychlokvasena. ocekaval bych vice o spojeni s X11 nebo pry i gnome ma neco na gtk.

[pavlix]

Podle mě by Pepa měl spíš použít pam_ssh, na svym počítači.

Ale díky za info.

P.S.: S Johankou se srovnávat nebudu.

[pavlix]

"Nejdřív je potřeba zařídit, aby se agent spouštěl a ukončoval, když se přihlásíte nebo odhlásíte."

To je myslim dostatečně popisný, ne? Matení čtenáře to není, Pepa má bash... a kdo bash nemá, tak většinou ví, že ho nemá.

Je pravda, že jsem mohl zmínit X11 prográmky, co se ptaj na heslo, ale na počítači, který můžu sám nakonfigurovat mi přijde mnohem pohodlnější nastavit ten pam_ssh, než zadávat dvě hesla. Tak mi přišlo lepší to trochu urychlit... než se dostanu k tomu zajímavýmu :).

[MartinT]

ssh -w

Díky za tip, desktop jedu na Ubuntu 6.06 LTS a to tohle ještě nemá :-o.

Pro běžné použití snad jen jako osobní VPN na vlastní server, je zapotřebí mít roota na obou stranách (konfigurace rozhraní tun) a defaultně je to na serveru zakázáno (což je dobře). Na rychlé/nouzové/dočasné zprovoznění tunelu ovšem ideální (možnost zprovoznění i přes http proxy via ProxyCommand, viz ssh_config). Pro trvalejší účely je IMHO lepší OpenVPN.

Ale i docela možný scénář pro Road Warriors:

- pam-ssh s nahráním klíče do ssh-agenta
- na serveru klíč klienta u roota v authorized_keys s restrikcemi:
tunnel="1",command="/usr/local/sbin/tuncfg.sh tun1; read",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
 * /usr/local/sbin/tuncfg.sh se stará o konfiguraci tun1
- server poslouchá na portu 443
- na klientu mít nějaký skript vpnviassh.sh co provede:
 * zaklepání, pokud se používá
 * nahození tunelu via ssh (ssh -C -f -w 0:1 -p 443 root@server)
 * konfigurace rozhraní tun0 přes "sudo /usr/local/sbin/tuncfg.sh tun0"
- do /etc/sudoers dát /usr/local/sbin/tuncfg.sh bez hesla, třeba takto
 * Cmnd_Alias TUNCONFIG = /usr/local/sbin/tuncfg.sh
 * %vpnusers ALL=NOPASSWD: TUNCONFIG

A Je tu poměrně jednoduchá VPN co projde i z restriktivních sítí s transparent proxy. Oproti stejnému postupu s OpenVPN je tu jen jedno heslo po přihlášení na klienta a na disku nikde neleží nešifrovaný klíč či heslo. Nevýhodou je asi maximální počet klientů dle počtu tun rozhraní na serveru (sdílení tunX point-to-point ? Či použití Level2 tunelu ?). Dále by bylo dobré vědět, jak se to chová v případě výpadku spojení (tcp timeout a pak to shodí tun0 ?) a jak je to s výkonností

[jiri.b]

ano objevilo se to od verze 4.3 http://openssh.com/txt/release-4.3

 * Add support for tunneling arbitrary network packets over a
   connection between an OpenSSH client and server via tun(4) virtual
   network interfaces. This allows the use of OpenSSH (4.3+) to create
   a true VPN between the client and server providing real network
   connectivity at layer 2 or 3. This feature is experimental and is 
   currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and 
   FreeBSD. Other operating systems with tun/tap interface capability 
   may be added in future portable OpenSSH releases. Please refer to 
   the README.tun file in the source distribution for further details
   and usage examples.

tu tvoji strategii jsem nepochopil...

jednodussi by bylo pouzit Match a AcceptEnv, ForceCommand a obalit to do skriptu, ktery se provede pri prihlaseni :)

do .ssh/config si date SendEnv a poslete nejaky string, ssh server to ochekuje a pripadne nastavi tunneling... dale LocalCommand :)

na kazdy si chce instalovat openvpn. samozrejme, ze skutecna VPN postavena na IPSec je lepsi reseni, ale toto je takovy rychly tip a taky takovy truc na openvpn :)

[Filip Jirsák]

Příště se odpoutáme od bezpečnosti a podíváme se, co nám může SSH nabídnout kromě očekávaného bezpečného připojení ke vzdálenému shellu. Dotazy a připomínky jsou vítány.

Mne by třeba jako námět do nějakého dalšího dílu zajímalo, zda existuje nějaká náhrada za vestavěný sftp_server pro subprotokol sftp, který v OpenSSH zamrzl na verzi protokolu sftp 3. Ta má tu "drobnou" nevýhodu, že neřeší kódování názvů souborů, což je v síťovém prostředí poněkud hloupé (pak z toho vzniká "já mám systém v UTF-8, tak se přizpůsobte"). Já naštěstí systém mám v UTF-8 a WinSCP je možné vnutit UTF-8 i pro sftp předverzí 4, takže jsem to vyřešil. Ale je to ostuda, že tentokrát je to program pro Windows, který je pružnější v nastavení a podporuje novější protokol.

[pavlix]

No... zrovna UTF-8 mi přijde jako docela dobrej a obecně použitelnej standard. Díky za připomínku.

[Filip Jirsák]

Což o to, já proti UTF-8 nic nemám, pokud se mají nějaké systémy sjednotit na kódování, většinou to zachrání UTF-8 (a pokud ani to ne, nepomůže už zpravidla nic). Ale přeci jen to ještě není tak daleko, abych mohl říct, že kdo nemá filesystém v UTF-8, s tím se prostě nebavím. Třeba Windows pořád používají ta svoje kódování, a to je docela dost instancí souborových systémů A tady bohužel opens source OpenSSH selhává, protože se musí okolní svět přizpůsobovat jemu, místo aby si OpenSSH poradilo s čímkoli – jak je jinak ve světě OSS zvykem.

[pavlix]

No... ve světě OSS je zvykem poradit si s čímkoliv... což je někdy skoro na škodu... ale to už je trochu offtopic polemika.

V tomhle konkrétním případě máš podle všeho pravdu.

[Jiri Bajer]

Trosku offtopic, ale obcas clovek potrebuje mit scp pristup ke stroji/VMWare s widlema. Osvedcil se mi miniaturni balicek orezaneho Cygwinu a OpenSSH, ktery roste na sshwindows.sourceforge.net.

[phero]

Vypáda zajímavě, díky.

[disorder]

mne sa zase osvedcil copssh, ktory nie je cez 3 roky stary...

[!]

vsichni teoretici necht radeji prestnou komentovat neco co ani na papire ani ve verbose debugu nevideli...

[pavlix]

heh?

[PavelP]

Chtěl bych varovat před přílišným optimizmem z pocitu bezpečí. Pokud má na serveru 'opravdové' účty třeba 30 lidí kvůli poště, tak se můžete vsadit, že 1/3 z nich má jako heslo jména svých dětí a do měsíce nějaký bot projde účty seznamem běžných loginů a slovníkem s hesly, vyjde mu to, stáhne /etc/passwd, projde slovníkem zbytek uživatelů a prolomené účty někam nabonzuje, načež vám někdo na server nasadí ručně nějakou potvoru.

[ghostmonk]

kdyz maj v /etc/passwd shell na /bin/false tak se tam zadna potvora nedostane

[Michal Kubeček]

Pokud má na serveru 'opravdové' účty třeba 30 lidí kvůli poště, tak se můžete vsadit, že 1/3 z nich má jako heslo jména svých dětí

Pro takové účely máme cracklib.

[David Jaša]

Pokud má na serveru 'opravdové' účty třeba 30 lidí kvůli poště, tak se můžete vsadit, že 1/3 z nich má jako heslo jména svých dětí...

Ti, co si alespoň jednou prolítli sshd_config(5) a zařídili se podle něj takové uživatele vůbec neřeší. :-P

[jiri.b]

pouzivat stejne heslo pro email a prihlaseni do systemu je opravdova imbecilita :)

nastavte si spravne SASL, pouzijte testovani slozitosti hesla systemoveho uctu pri jeho zadavani.

a pokud nepouzivaten nejaky rozumny system, udelejte si skripty, ktere kontroluji pres cron prava na dulezitych souborech...

[Filip Jirsák]

Používat více hesel k ověření jednoho uživatele je opravdová imbecilita Čím více hesel musí člověk používat, tím ta hesla budou slabší a spíš budou někde napsaná na monitoru.

[jiri.b]

aha... ok priklad, uzivatel si nainstaluje svuj oblibeny MUA a nejak nahodou zapomene povoli/zaskrtnou, ze to ma byt pres SSL = heslo prozrazeno :)

samozrejme resenim muze byt striktne vynutit pouze TLS/SSL spojeni... I presto, obcas neni naskodu byt iniciativni :)

[Filip Jirsák]

Pokud používám stejné heslo pro e-mail i přihlášení, musím šifrování samozřejmě vynutit. Teoreticky je samozřejmě nejbezpečnější jedno heslo pro jednu službu, co nejdelší a nejsložitější hesla, jejich častá obměna, ideálně jednorázová hesla. Jenže ta hesla musí pořád používat lidi, což je nejslabší článek. Takže musím zajistit především to, aby se lidem ta hesla snadno používala – tj. když už konečně vymyslí nějaké bezpečné heslo, nebudu je nutit vymýšlet každé dva měsíce nové. A budu počítat s tím, že si to jedno heslo zadají stejně i k ostatním systémům, akorát jej budou muset víckrát zadávat – větší šance odpozorování. Takže dám raději jeden způsob přihlašování a pokusím se vše nastavit tak, aby přihlášení k počítači už bylo přihlášení ke všem systémům (takže kde to jde použiju např. k přihášení certifikáty, které může mít uživatel u sebe nainstalovány).

[pavlix]

No já bych řekl, že teoreticky jsou nejbezpečnější klíče. A pokud se k nim člověk chová jak má, tak i prakticky. Ale bezpečnostní expert nejsem, i když mě tahle tématika dost zajímá.

No a jedna nebo dvě passphrase + několik hesel, kde to jinak nejde... to už se nějak zvládne.

Ještě se mi docela teoreticky líbí digest authentication, ale ještě jsem to nikde neviděl pořádně (tj. tak, aby čisté heslo nešlo na server ani při registraci ani nikdy potom).

[zelial]

prepadla me nostalgie. taky jsem si kdysi cetl "how to be a hacker" a podobne zarucene navody. k namitkam, co tu padly, pridam jeste /etc/shadow.

[pavlix]

Díky... zrovna jsem chtěl ten shadow zmínit...

Opravdu to chce aspoň znát svuj systém, když už člověk řeší SSH v pokročilejším měřítku... než instalace+přihlášení heslem.

[pavelp]

Jasně, v passwd hesla nějaký pátek nejsou, shadow nikdo nepřečte. úplně původní příspěvek měl pouze varovat, že otevření ssh do světa spolu se slabými uživatelskými hesly je pěkná kravina. A uhodnutí 20% hesel po prolomení jednoho účtu je pak celkem lehké a není k tomu třeba znát jejich hash. S popsaným scénářem jsem se prakticky setkal, pro člověka co instaloval onu potvoru to byla naštěstí rutina, nesnažil se o nic jiného ani nepátral po drobných naschválech co jsem mu prováděl.

[Smazáno]

Hmmm, už to umí chroot po navázání spojení? Alespoň podle $USER?

[Jouda]

na chroot zkuste toto: http://chrootssh.sourceforge.net/index.php

[jiri.b]

otazka neni jestli to umi chroot, ale jestli neco umi omezit uzivatele aby nemohl prochazet jine slozky nez tu svoji...

chroot je nesystemove a slozite reseni. reseni existuje, nejaky Mandatory Access Control :P

[Jouda]

Ano, ale to už se nebavíme o OpenSSH. Omezení uživatelů není věcí ssh, ale systému. V případě MAC se ale trošku mýlíte. Proti MAC (mandatory access control) je chroot trivialita.

[pavlix]

Zavřít uživatele do chrootu po navázání spojení samozřejmě jde. Ale ani k tomu není potřeba podpora ze strany SSH serveru.