Názory k článku ssh intimně aneb úvod do paranoii 2
-
Článek je starý, nové názory již nelze přidávat.
-
Yeti (neregistrovaný)
Nesmí se to přehnat. Jednou se mi podařila pěkně vypečná chyba: Při nějakém přesunu authorized_keys2 mezi stroji jsem na něm nějak vyrobil g+w. Asi byl někde každý uživatel ve své grupě a navíc byl nějaký divný umask, těžko říct. Sice se zase tak moc nestalo, protože práva na ~/.ssh byla v pořádku, ale paranoidní ssh odmítlo takový soubor vzít na vědomí a já jsem nechápal (pěkně dlouho :-) proč se tam sakra nejde nalogovat přes passphrase. Takže když nepomůže přidávání práv, zkuste ubrat :-)
-
Tritol (neregistrovaný)
Tenhle problem jsem mel taky (vice uzivatelu musi mit plny pristup k jednomu spolecnemu uzivateli). Sshd lze premluvit, aby nebyl tak paranoidni pres "StrictModes no" v sshd_config.
btw: dost mi vadilo, ze ssh pri zahajeni pripojeni pomerne dlouho ceka. Nakonec jsem zjistil, ze na vine je pravdepodobne implementace ipv6, pokud se ssh spusti s parametrem -4, je vsechno temer okamzite.
btw#2: jedna se o OpenSSH 3.4p1 (server) a 3.5p1 (klient) -
ivan (neregistrovaný)
Pridam takovou perlicku o pouzivani klicu.
Pokud vam na AIXu nefunguji RSA klice tak je to protoze:
1. domovskym adresarem root-a je root(/)
# ls -ld /
drwxr-xr-x 26 bin system 1024 Mar 31 ...
2. vlastnikem / je user bin a ne root
3. ssh odmitne pracovat s adresarem /.ssh
resenim je "chown root /" - menit domovsky adresar
uzivatele root se VELICE nedoporucuje.
Pokud vam ani po teto procedure nefunfuji DSA klice
pak vezte ze je to chybou v gcc a ze openssl nejde na AIXu poradne prelozit. Pouzijte CVS verzi gcc nebo jeste lepe Cecko od IBM. -
Petr Ferschmann (neregistrovaný)
Rad bych poznamenal, ze moznost mit na obou stranach klic, abych se mohl prihlasovat mezi obema stroji je trosku nebezpecne (viz tento clanek a odchyceni hesla pokud chteji klice pro svoji funkci alespon heslo. Pak uz nic nebrani :-).
IMHO je lepsi pouzivat ssh-agenta. Pridate si do nej zaheslovany klic a pak se prihlasite na stroj. Pokud tomuto stroji duverujete muzete si nechat agenta forwardovat. Pak se muzete prihlasit zpet. Vyhodou je, ze klic neopusti Vas pocitac (agent jen sifruje a desifruje data). A pokud nekdo hackne cilovy stroj muze zneuzit agenta jen po tu dobu co jste prihlaseni (spojeni na agenta je v $SSH_AUTH_SOCK). A dostat klic z agenta nejde (pokud nemuzete analyzovat primo pamet ve ktere bezi :-).
PS: po prihlaseni do X-ek jste si jiste vsimli spusteneho programu ssh-agent - to je on :-).
Prikazem "ssh-add" si do nej pridate klice. Pripadne se to zepta na heslo. Existuji k tomu i graficke dotazovace na heslo. Takze po prihlaseni staci pridat jen zasifrovane klice :-). -
Malviny (neregistrovaný)
Ahoj Johanko,
rekl bych, ze pri tom navazani komunikace je to trochu jinak (nebo jsem spatne pochopil napsane? Cetl jsem si to nekolikrat...). Budu se drzet konvence klient krtecek a server pikatchu.
A: Navazani sifrovaneho spojeni:
A1: krtecek pozada pikatchu o pikatchu_public_key.
A2: krtecek vygeneruje CISLO1, zasifruje jej pomoci pikatchu_public_key a vysledek posle pikatchu
A3: pikatchu si pomoci pikatchu_private_key odkryptuje CISLO1, ktere pak pouzivaji pro sifrovani spojeni
B: Overeni, ze krtecek je skutecne krtecek (deje se jiz na sifrovanem spojeni)
B1: krtecek posle pikatchu krtecek_public_key
B2: pikatchu se koukne do authorized_keys, jestli tam krtecek_public_key ma, pokud ano, vygeneruje CISLO2 a posle krteckovi CISLO2 zasifrovane pomoci krtecek_public_key
B3: krtecek pomoci krtecek_private_key odsifruje zasifrovane CISLO2 a posle pikatchu odsifrovane CISLO2
B4: pikatchu porovna zaslane CISLO2 s puvodnim CISLO2, pokud jsou stejne, krtecek uspesnym odsifrovanim prokazal, ze je skutecne krtecek
Umyslne jsem vynechal zbytne veci, napr. v A ze krtecek si v realu mezi A1 1 A2 zkusi najit pikatchu_public_key ve svem seznamu, pokud ho tam nema, umozni doplneni seznamu, pokud ma, ale lisi se, tak zarve, atd. -
Johanka (neregistrovaný)
Jo, mela jsem to tam nejak blbe, coz vyplynulo z toho, ze Lace me na posledni chvili zmatl nejakymi tvrzenimi a ja si to pak nenechala zkontrolovat :) My fault. Ale doufam, ze hruba ideologie zustala zachovana, vliv na navody to nemelo a tedy me nikdo neukamenuje. Jinak o klici serveru uz jsem se ted ani nezmilovala, ten byl minule (a doufam, ze dobre :)).
Diky -
Jan Lace Kratochvil (neregistrovaný)
Hmm, ta zenska si neda pokoj a musi tam popisovat protokol, ac to z bezpecnostniho hlediska IMO postrada vyznam, dulezity je, kdo ma privatni vs. verejny klice a co je z toho exploitnutelne a spoofovatelne po siti.
On je tady trochu bordel v tom, ze SSH-1 a SSH-2 se v techto vecech lisi. Clanek se tyka ciste SSH-2, Vy popisujete SSH-1. Bohuzel jsem puvodne johance posilal popis SSH-2 s castmi SSH-1 (uz se mi to smichalo nebo jsem si to uz nepamatoval, co ja vim), teprve posleze se opravil na realne SSH-2, bohuzel v clanku pak vznikla kombinace obeho. :-)
Co se tyce Vasich A* bodu o host-key, tak tech se tykal jen 1. dil serialu, ale do detailu protokolu nezabihal. Minimalne Vam tam jeste chybi dulezity Diffie-Hellman Key Exchange algoritmus pro prevenci dekodovani spojeni pasivnim man-in-the-middle i v pripade znalosti privatniho klice serveru. Diffie-Hellman v SSH-1 chybel.
Body B* mate take psany dle SSH-1. SSH-2 jiz pouze vezme verejny autentikacni klic a podepise ho jeho privatni casti, coz pak zasle spolecne s verejnou casti serveru, ktery si overenim podpisu overi, ze klient privatni cast potrebnou pro podpis zna.
Pro clanek i tento comment cerpano z: http://www.ietf.org/html.charters/secsh-charter.html -
Petr Vagera (neregistrovaný)
Pri hledani problemu (u OpenSSH) musite zkontrolovat vsechna tahle prava:
$home
$home/.ssh
$home/.ssh/authorized_keys*
pokud mate pro svuj $home povoleno treba g+w tak to sshd odmitne (logicky) jako neduveryhodne pro authorized_keys. Dle teto konstrukce by sshd mel asi zkontrolovat i celou cestu z $home do /, ale to jsem neoveroval ;-) -
jk (neregistrovaný)
1. stroje - OpenSSHckovy tipuju artax, atrey. Z dalsich tipu arc.ucw.cz (?), chroustalka, ghost.cybernet.cz, mozna jeste neco na .ms.mff, .4web
odduvodneni:
last johanka; fgrep johanka /var/log/maillog;
dix AXFR ucw.cz @drak.ucw.cz | cut -f 1 | xargs -ikde "johanka@kde"; atp.
2. Nastavit si autentizaci "tam i zpet" znamena, ze se zase objevi stare zname problemy s patchnutym ssh a sshd. To bych zminoval jen s nekolika vykricniky a pokud je absolutne nutne. Zpravidla staci ssh agent forwarding.
Osobne za nejvetsi vyhodu klicu pro bezneho usera povazuji to, ze mi staci pamatovat si jednu passphrase. Pokud si rozeseju na radu pocitacu n klicu, musim si zase pamatovat n hesel.
3. Vic private klicu se hodi na ruzne "advanced" techniky, kdy s konkretnim klicem je na serveru spojen konkretni prikaz (treba shutdown -r).
4. Duvodem k pouziti ssh1 muze byt to, ze napriklad na handheldu je dostupny jen ssh1 klient. Ssh 1 toho taky mene umi a proto se lepe "orezava", takze sve pouziti si dosud najde.
5. Vic rootu, ktere muzu separatne mazat, se da udelat pres vic useru s uid 0 (root1, root2, ...). K "polorootum" existuji nastroje jako sudo, pokud je to hodne slozite, tak RSBAC a spol. Udelat vic rootu tak, ze v ssh povolim root login, a rozdam vic klicu, nelze doporucit.
6. extempore s scp a prejmenovavanim cehosi kamsi si v openssh muzeme odpustit prikazem
cat id_dsa.pub | ssh jk@atiks "cat >> .ssh/authorized_keys2" -
johanka (neregistrovaný)
1) Zda u me lizatko mas, pripadne za co + formalni detaily, doladime mailem, at nekazime hru :)
5) Jo, da se to, my tu mame taky dva, ale je v tom pak bordel... Ja osobne jsem rozdala ssh klice pouze z lokalnich uctu (protoze nikdo z rootu na mem routeru neumi udelat klic mezi OpenSSH a SSH :), nemusim se bat, ze si daji i remote, ale po pristim dilu serialu uz to umet budou..)
6) I tak :) Ale neni to zas tolik nazorny :) -
Zdenek (neregistrovaný)
Tip, který mě stál několik hodin života:
Součástí HP distribuce SSH pro HPUX 11i (produkt T1471AA) je sshd, který podporuje PAM. A PAM na HPUX zase podporuje TCB (Trusted Computing Base) a s ním souvisící bezpečnostní politiky včetně stárnutí hesel.
Takže: hlásíte-li se na HPUX autentizací RSA (případně DSA) klíčem, který je na tuty v pořádku a stejně to po Vás chce heslo, načež po jeho (tutově správném) zadání Vás to stejně vyhodí, je to velmi pravděpodobně tím, že Vám prostě vypršela platnost hesla. -
Zdenek (neregistrovaný)
Tip, který mě stál několik hodin života:
Součástí HP distribuce SSH pro HPUX 11i (produkt T1471AA) je sshd, který podporuje PAM. A PAM na HPUX zase podporuje TCB (Trusted Computing Base) a s ním souvisící bezpečnostní politiky včetně stárnutí hesel.
Takže: hlásíte-li se na HPUX autentizací RSA (případně DSA) klíčem, který je na tuty v pořádku a stejně to po Vás chce heslo, načež po jeho (tutově správném) zadání Vás to stejně vyhodí, je to velmi pravděpodobně tím, že Vám prostě vypršela platnost hesla. -
petr andrs (neregistrovaný)
IMHO pikatchu je artax (nebo artax je pikatchu?)
Postup: proste me napadlo, ze jeden ze stroju by mohl byt artax, tak sem se prihlasil a fingerprint vysel na pikatchu viz.:
[Administrator@tonda:~]$ ssh artax.karlin.mff.cuni.cz
The authenticity of host 'artax.karlin.mff.cuni.cz (195.113.31.125)' can't be established.
RSA key fingerprint is 44:30:d2:89:dd:f8:8a:af:d0:b4:46:73:9f:2e:9f:5c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'artax.karlin.mff.cuni.cz,195.113.31.125' (RSA) to the list of known hosts.
A domaci ukol z minula: klice mam na widlich v ~/.ssh coz je mem pripade take jinymi slovy C:\cygwin\home\Administrator\.ssh, OpenSSH_3.5p1
Jinak nac vic klicu, staci vsude ten samy, passphrase zasadne prazdna prave proto abych nemusel furt zadavt heslo, -
Jeff (neregistrovaný)
Nevim jestli to bylo naschval, ale jedna ip byla opravdu zajimava
The authenticity of host 'pikatchu (197.121.273.10)'
can't be established.
RSA1 key fingerprint is
43:e6:48:70:e1:87:58:1f:62:91:13:f6:02:67:d9:15.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'pikatchu, 197.121.273.10'
(RSA1) to the list of known hosts.
Ze by neco mezi IPv4 a IPv6? ;-)
Jeff.
