Când m-am referit la PKI m-am referit la perechi de chei SSH (publice/private).
În general nu este bine din punct de vedere al securității ca partea privată a unei perechi de chei SSH să fie transmisă prin internet.
Atunci cănd trebuie să gestionezi doar cheile proprii (două, trei, poate cinci) nu apar probleme majore, însă când trebuie să gestionezi cheile pentru mai mulți utilizatori (echipe de devi) și eventual trebuie să implementezi și politici stricte de securitate (rotația cheilor la interval definit de timp) lucrurile devin foarte complicate. Pentru asta ajută foarte mult folosirea Certificatelor OpenSSH.
Ceva exemplu:
Dacă vreau să-ți dau acces la o mașină pe SSH folosind perechi de chei de criptare avem 2 variante:
- Eu generez o pereche de chei de criptare și trebuie să fac cumva să îți parvină partea privată pentru a putea să te conectezi cu ajutorul ei. Dacă vii la birou ti-o dau și momentan e ok, dacă lucrezi remote nu e tocmai ok să ți-o trimit prin internet - aici e o discuție intreagă. Dacă trebuie să o înlocuiesc după o lună (sau 3) confirm politicii de securitate a organizației, trebuie să mai generez o pereche și să ți-o trimit pe cea nou generată cumva, iar.
- Tu ai o pereche de astfel de chei și îmi trimiți jumătatea publică pentru a o adăuga în fișierul de chei autorizate pentru utilizatorul alocat conexiunii. Fiind partea publică nu e nici o problemă să mi-o trimiti de exemplu atașată la un email. Eu o instalez în fișierul de chei autorizate. Pare simplu! Însă lucrurile se complică rapid dacă folosesc un bastion host (jump host), dacă trebuie să asigur acces ssh la o flotă de mașini (fizice sau virtuale), dacă trebuie să asigur accesul la 5 (sau poate 15) oameni dintr-o echipă, și desigur dacă trebuie să rotesc cheile peste o lună. Cel mai probabil aș vrea ca fiecare membru al echipei să aibă o pereche de chei distincte pentru fiecare serviciu în parte pentru a asigura trasabilitatea necesară.
Sunt multe opțiuni și variante de avut în vedere, de discutat, de gestionat și implementat la nivel de proceduri, fluxuri de lucru etc, însă deja m-am lungit destul de mult.
Cert este că folosirea certificatelor SSH ajută în mod substanțial să scăpăm de toată această imensă durere de cap. Practic acestea sunt motivele principale pentru care Github a implementat de ceva timp utilizarea certificatelor SSH, pe bani însă pentru servicii Enterprise.
Pe scurt, cum ajută Certificatele SSH:
a. Poți folosi o pereche de chei pe care o ai la dispoziție (practic oricare).
b. Îmi trimiți cheia publică pentru a te putea identifica.
c. Când dorești un acces la un serviciu/sistem/host etc pe care eu îl gestionez, soliciți un Certificat SSH. Solicitarea conține informații despre cheia ce va fi folosită pentru acces, intervalul de timp în care se realizează accesul, utilizatorul de sistem folosit pentru acces.
d. Eu emit Certificatul care codează toate aceste informații, pe care ți-l pot trimite fără probleme prin internet (Certificatul este public).
e. Cu certificatul și cheia privată aferentă (poți să) te conectezi doar în intervalul de timp stabilit, doar cu utilizatorul de sistem stabilit, doar la serviciul/hostul stabilit.
Nu am probleme să editez fișiere de chei autorizate pentru a-ți asigura accesul, nu am probleme dacă ești dezordonat și îți ții cheile private pe 7 stick-uri, pe 3 calculatoare, în 5 conturi de emai, pe dropbox, sau altundeva aiurea, nu am probleme dacă te-ai supărat pe mine sau pe echipă și pleci și trebuie să-ți limitez accesul din momentul zero în care ai pus demisia pe masă, nu am probleme dacă ți-a furat cineva laptopul și tu aveai niște chei private pe acolo, nu am probleme dacă ți-ai dus telefonul la reparat la buticul de la Mall și tu (iar) ai niște chei rătăcite într-un folder, etc…
Până acum pentru Windows, doar Clientul OpenSSH din Windows suporta aceste Certificate (desigur aici nu mă refer la alte implementări SSH Client și Server existente pe piață, despre care momentan nu sunt la curent să implementeze specificațiile OpenSSH Certificates). Pentru sistemele Linux clientul SSH implicit este OpenSSH și deci suportul pentru Certificate SSH este prezent din primul moment în care specificația a fost implementată și disponibilă.
De ce e bine că … putty?
- Pentru că este cel mai folosit client SSH pe Windows. Multă lume încă nu știe că există OpenSSH portat pe Windows și oferit chiar de Microsoft. Fiind disponibilă utilizarea Certificatelor folosind Putty sunt șanse să crească la modul general utilizarea Certificatelor SSH și astfel se îmbunătățește securitatea în multe locuri, medii de lucru etc, ceea ce cred că este un lucru bun în ansamblu.
- Pentru că pot să evit să folosesc agentul SSH oferit de Windows și să folosesc de exemplu PageAnt. Aici iar poate fi o discuție întreagă, însă pe scurt, dacă am o cheie privată protejată cu parolă și am încărcat-o odată în agentul ssh oferit de Windows, ea rămâne acolo chiar dacă restartez (hard reset) mașina Windows în cauză (poate fi eliminată dacă te chinui suficient de mult, însă nu asta e ideea).
- Pot folosi ce client doresc pentru acesul unor repozite software (git over ssh) din IDE-ul pe care îl folosesc, și astfel pot să elimin apariția ferestrei CMD prompt la fiecare commit (sau la fiecare acces al repozitului respectiv - vezi implementarea Tortoise Plink al cărui unic scop în viață este acesta).
- Nu în ultimul rând este valabil și motivul invocat de tine: că are GUI. Dar sunt și diverse probleme de uzabilitate care sunt rezolvate diferit în funcție de interfață utilizată. Nu știu dacă mai bine sau mai rău, dar diferit, și oamenii s-au învățat intr-un anume fel. Pot să-ți dau un exemplu personal aici: dublu-click în linia de comandă în putty mie îmi selectează toată linia (fără să selecteze și prompt-ul); dublu-click în Windows Terminal într-o sesiune ssh deschisă îmi selectează ce este între 2 “forward slash-uri” adiacente. Chestia asta m-a tocat mărunt la nervi și la viteză de operare!
