Autentificare SSH cu chei – partea I
SSH (Secure SHell) a devanit de cativa ani modalitatea standard de administrare la distanta a sistemelor Unix, acest lucru datorandu-se in primul rand faptului ca ofera o conexiune criptata, care asigura confidentialitatea datelor transportate (in primul rand a parolelor).
Dar protocolul SSH are si alte caracteristici extrem de utile, una din ele fiind autentificarea cu cheie privata.
In situatia in care ai de administrat foarte multe sisteme, apare o dilema: cum tii minte toate parolele? Imi permit sa citez aici un post din 2001 de-al lui Florin Andrei :
Daca ai de la 10...15 [nr: sisteme] in sus, sint citeva posibilitati:
- Pui aceeasi parola peste tot (si te lasi de meserie)
- Pui parole simple (si te lasi de meserie)
- Schimbi parolele foarte rar (si te lasi de meserie)
- Iei pastile de tinut minte (cca o lopata pe zi, dupa un an te lasi si de meserie si de viata)
- Te gindesti totusi la o metoda sa le notezi
Metoda pe care o descria in acel post este foarte geek si generalizabila la orice fel de informatii secrete, dar daca ne limitam la SSH, exista o metoda software echivalenta, si anume folosirea unei chei private.
Teoria criptarii asimetrice si a perechilor de chei este relativ cunoscuta si nu tin s-o expun aici, dar pe scurt este vorba de o pereche de chei (sa le zicem K1 si K2) generata de asa natura incat nu se poate obtine una din cealalta, precum si un algoritm de criptare universal cunoscut. Natura algoritmului si a perechii de chei este de asa natura incat un mesaj criptat cu una din chei, sa zicem K1, poate fi decriptat doar avand cheia K2 (oarecum ca doua jumatati de medalion 
). Se desemneaza una din chei ca fiind privata (si se pazeste foarte bine, vezi mai jos), iar cealalta se poate distribui liber.
Cum se aplica asta la SSH? Simplu. Se copiaza in prealabil cheia publica pe serverele la care se doreste conectarea si se pastreaza cheia privata. La conectare, daca serverul a fost configurat asa (si de obicei este), se face o verificare intre cele doua chei. Daca se potrivesc, se permite accesul, fara a se mai solicita parola.
Avantaje:
- nu trebuie tinuta minte parola;
- parola poate fi schimbata oricand (pentru accesul de la consola, sau de catre un program), accesul persoanelor cu cheie ramane asigurat;
- se poate usura accesul diverselor scripturi care folosesc tunele ssh (este mult mai complicat sa simulezi introducerea inei parole);
- atata timp cat cheia privata nu e compromisa, se poate garanta identitatea persoanei care s-a logat;
- poate fi dezactivata complet autentificarea cu parola, eliminand astfel din discutie posibilitatea de bruteforce.
Dezavantaje:
- este imperativ sa nu se compromita cheia privata, posesorul trebuie sa se asigure ca are un passphrase suficient de sigur si ca nu exista mai multe copii ale cheii;
- nu se poate aplica si altor metode de autentificare, este un procedeu specific ssh (anumite servicii au metode similare, totusi);
- nu simplifica foarte mult revocarea accesului unei anumite persoane (trebuie stearsa cheia publica de pe servere, totusi nu implica schimbarea parolei in cazul in care contul este utilizat de catre mai multe persoane).
Dupa cum se constata usor, calcaiul lui Ahile il constituie secretul cheii private. Procedura recomandata este (pe langa securizarea accesului la fisierul propriu-zis) criptarea cu un passphrase suficient de puternic (cel putin peste 20 de caractere cat mai diverse) care se memoreaza si nu se noteaza nicaieri, nu se spune nici cainelui, nevestei sau duhovnicului. Pai si ce-am facut? Am inlocuit o varietate de parole cu una singura foarte grea care trebuie tastata de fiecare data? Umm, teoretic da. Practic, au aparut programele de tip agent, carora nu trebuie sa le dai decat passphrase-ul, se ocupa de chei fara sa mai ceara indicatii (si cu care clientul ssh stie sa discute, evident).
Despre implementarile practice ale autentificarii ssh cu chei, intr-un articol viitor.