Traducerea articolului de Daniel Robbins Managementul cheie OpenSSH, Partea 2
Mulți dezvoltatori folosesc minunatul program OpenSSH ca înlocuitor securizat criptat pentru comenzi arhaice telnet și rsh. Una dintre cele mai interesante caracteristici ale OpenSSH este capacitatea sa de a autentifica utilizatorii care folosesc protocolul de autentificare RSA și DSA, care se bazează pe o pereche de „chei“ complementare numerice. Unul dintre aspectele cele mai atractive ale autentificării RSA și DSA este capacitatea lor potențială de a stabili conexiuni la sistemele la distanță fără a specifica o parolă. În acest al doilea articol, Daniel vă prezintă ssh-agent (un cache cheie privată) și Keychain - script personalizat bash, concepute pentru a face autentificarea cheie pe bază este extrem de convenabil și flexibil.
Cunoașterea cu agentul ssh.
Inclus în distribuția de OpenSSH ssh-agent - un program special conceput pentru a face de lucru cu RSA și DSA chei plăcute și sigure (a se vedea prima parte a acestei probleme pentru a revizui RSA- și DSA-autentificare). Spre deosebire de ssh. ssh-agent este un daemon care funcționează în mod constant, creat exclusiv pentru caching-ul cheilor private decriptate.
Ssh include built-in instrumente de sprijin care îi permit să comunice cu ssh-agent „th, și ssh-agent“ la - primi cheile private decriptate nu vă invită să introduceți o parolă la stabilirea fiecare conexiune nouă. Când lucrezi cu ssh-agent "folosești doar ssh-add. Pentru a adăuga cheia dvs. privată la cache-ul agentului ssh-agent. Acest lucru se face o dată; după utilizarea ssh-add. ssh va extrage cheia dvs. privată de la ssh-agent 'a, în loc să vă dea o invitație de a introduce o expresie cheie.
Folosind ssh-agent.
Să ne uităm la modul în care funcționează întregul sistem de caching al sistemului ssh-agent. Când se pornește agentul ssh. apoi înainte de a se separa de coajă și de a continua munca de fundal, dă muntelui mai multe variabile importante de mediu. Iată un exemplu de ceea ce poate produce ssh-agent la pornire:
După cum puteți vedea, rezultatul informațiilor ssh-agent este de fapt o serie de comenzi bash; Dacă aceste comenzi sunt executate, acestea vor configura două variabile de mediu: SSH_AUTH_SOCK și SSH_AGENT_PID. Datorită comenzilor de export incluse, accesul la aceste variabile de mediu poate fi obținut prin orice comenzi suplimentare lansate ulterior. În general, totul se va întâmpla exact în acest caz, dacă shell-ul evaluează cu adevărat datele din linii, dar în acest caz ele sunt pur și simplu de ieșire la stdout. Pentru a corecta situația, putem apela ssh-agent în felul următor:
Această comandă spune bash-ului să ruleze ssh-agent și să calculeze datele pe care le afișează. Provocate în acest mod (cu back-citate, nu de ghilimele simple obișnuite) și variabilele SSH_AGENT_PID SSH_AUTH_SOCK va fi instalat și exportat în coajă, ceea ce face aceste variabile disponibile la orice procese noi ar putea începe în timpul funcționării.
Cea mai bună modalitate de a începe ssh-agent este să adăugați o linie în partea superioară a fișierului
/.bash_profile. În acest caz, toate programele care rulează în shell-ul de conectare vor vedea variabilele de mediu, pot localiza agentul ssh și, dacă este necesar, pot solicita chei din el. O variabilă de mediu extrem de importantă este SSH_AUTH_SOCK. SSH_AUTH_SOCK conține ruta către socket-ul de domeniu UNIX, pe care ssh și scp le poate utiliza pentru a stabili un dialog cu ssh-agent ".
Folosind ssh-add.
Dar, desigur, atunci când executați ssh-agent "și cache-ul său nu conține chei private decriptate. Înainte de a putea folosi agentul ssh. trebuie să adăugăm cheia noastră privată la cache-ul ssh-agent și să folosim comanda ssh-add. În exemplul de mai jos, folosesc comanda ssh-add pentru a-mi adăuga cheia personală RSA
/.ssh/identity în cache-ul ssh-agent.
După cum puteți vedea, ssh-add a cerut să-mi expresia de acces a decripta cheia privată, care este apoi gata de utilizare și vor fi stocate în memoria cache ssh-agent. Acum, că ați folosit comanda ssh-add pentru a adăuga cheia dvs. privată la cache-ul ssh-agent. și în shell-ul curent variabila SSH_AUTH_SOCK este definită (și trebuie definită dacă ați executat ssh-agent din
/.bash_profile), puteți utiliza scp și ssh pentru a stabili conexiuni la sistemele la distanță fără a specifica fraza de acces.
Limitări ale agentului ssh.
ssh-agent este un lucru foarte cool, dar setările implicite au încă unele inconveniente minore. Să le analizăm.
Într-un caz, asociat cu eval `ssh-agent` în
/.bash_profile, pentru fiecare sesiune este pornită o nouă copie a ssh-agent. și aceasta înseamnă nu numai crearea de etichete suplimentare, ci și faptul că trebuie să utilizați ssh-add pentru a adăuga o cheie privată fiecărei copii noi a ssh-agentului. Nici o problemă mare dacă deschideți un singur terminal sau consola de pe sistemul dvs., dar cele mai multe dintre noi deschide mai multe terminale și sunt forțați să intre în expresia de acces de fiecare dată când deschideți o nouă consolă. În mod formal, nu există niciun motiv pentru care trebuie să facem acest lucru cu siguranță, în timp ce o singură acțiune în ssh-agent ar trebui să fie suficientă.
O altă problemă cu setările implicite ale ssh-agentului este că nu este compatibilă cu joburile cron. După operațiile cron sunt executați procesul de cron, ei nu moștenesc din mijlocul lor variabila SSH_AUTH_SOCK, și, prin urmare, nu știe nici că procesul de ssh-agent se execută sau cum să le contactați. După cum sa dovedit, această problemă este, de asemenea, rezolvată.
Introducerea brelocului.
Pentru a rezolva aceste probleme, am scris un client bazat pe bash pentru ssh-agent. numit keychain. Un keychain special este faptul că vă permite să utilizați un proces separat ssh-agent pentru fiecare sistem, mai degrabă decât pentru fiecare sesiune. Aceasta înseamnă că va trebui să utilizați o singură dată pentru fiecare cheie privată ssh-add și asta-i tot. După cum vom vedea mai târziu, keychain-ul ajută deja la optimizarea procesului comenzii ssh-add, chiar și cu încercările lor de a adăuga chei private la cache-ul de lucru ssh-agent, care nu există încă.
Iată o scurtă trecere în revistă a modului în care funcționează keychain-ul. Când este rulat dintr-un fișier
/.bash_profile, verifică mai întâi dacă ssh-agent rulează sau nu. Dacă nu, va rula ssh-agent și va scrie variabilele importante SSH_AUTH_SOCK și SSH_AGENT_PID în fișier
/.ssh- agent pentru securitate și posibilitatea utilizării ulterioare. Aici este cel mai bun mod de a porni cheia de breloc; ca atunci când folosim un agent vechi bun ssh, vom efectua setările necesare
După cum puteți vedea, pentru brelocul de chei folosim fișierul sursă ca fișier sursă
/.ssh-agent, în loc de a evalua rezultatul, ca și în cazul utilizării directe a agentului ssh. Deși rezultatul este același: o variabilă extrem de importantă SSH_AUTH_SOCK este definită, ssh-agent este sus și gata de plecare. Și din moment ce SSH_AUTH_SOCK este scris într-un fișier
/.ssh-agent, scripturile propriilor noastre conturi de shell și cron pot comunica cu ușurință cu agentul ssh folosind pur și simplu informații din fișier
/.ssh-agent. Chirpiciul în sine folosește de asemenea acest fișier. Amintiți-vă că atunci când porniți, cheia verifică dacă ssh-agent rulează. Dacă rulează, atunci cheia va folosi fișierul
/.ssh-agent pentru a solicita setările exacte pentru variabila SSH_AUTH_SOCK, aceasta îi va permite să folosească un agent deja activ și să nu deschidă unul nou. keychain va porni noul proces ssh-agent numai în cazul în care fișierul
/.ssh-agent este depreciat (se referă la un agent ssh deja existent) sau dacă fișierul în sine nu există.
Instalarea brelocului.
Instalarea brelocului este ușor. Mai întâi, accesați pagina proiectului de chei și descărcați cea mai recentă versiune a brelocului cheie din arhivă. Apoi instalați-l după cum urmează:
Acum, când lanțul de chei este în directorul dvs. / usr / bin /, adăugați-l în fișierul dvs.
/.bash_profile, specificând calea spre cheile dvs. private ca argumente. Iată un bun exemplu
/.bash_profile cu cheia de chei activă (activată cu cheia
/.bash_profile cu un breloc de chei valabil
Keychain în acțiune.
Acum ați înființat
/.bash_profile apelați cheia de chei de fiecare dată când vă conectați, deconectați-vă și reveniți. Când se întâmplă acest lucru, keychain va rula ssh-agent și va scrie caracteristicile de instalare ale variabilei de mediu a agentului în fișier
/.ssh-agent și vă solicită apoi parole cheie pentru fiecare cheie privată specificată în linia de comandă a keychain-ului din fișier
Keychain-ul începe pentru prima dată.
După ce introduceți expresii cheie, cheile dvs. private vor fi stocate în cache, iar brelocul va fi înlăturat. Apoi va fi folosit
/.ssh-agent, care inițializează sesiunea cu ssh-agent. Acum, dacă vă deconectați și să reintroduceți, veți vedea că Keychain va detecta un proces deja activ de ssh-agent (nu se încheie la cererea de retragere din sistem). În plus față de tot, keychain-ul va confirma prezența cache-ului agentului ssh-agent în cheile private pe care le-ați specificat deja. În caz contrar, veți primi o invitație de a efectua fraze cheie corespunzătoare, dar dacă totul este în ordine, atunci actualul ssh-agent trebuie să conțină în continuare chei private adăugate anterior (acest lucru înseamnă că nu se va cere să introduceți parola):
Keychain detectează un agent ssh valid
Felicitări: tocmai v-ați conectat și acum puteți utiliza ssh și scp pentru sistemele la distanță. Nu trebuie să utilizați ssh-add imediat după autentificare și nici ssh, nici SCP nu vă va cere să introduceți o expresie de acces. De fapt, în timp ce procesul inițial al agentului dvs. ssh funcționează, puteți să vă conectați și să stabiliți conexiuni ssh fără a introduce o parolă. Și este probabil că procesul de agent ssh va continua să funcționeze până când aparatul va fi repornit. Având în vedere că ați instalat cel mai probabil aceste programe pe un sistem Linux, atunci probabil că nu veți avea nevoie de o parolă timp de câteva luni! Bine ați venit în lumea conexiunilor securizate fără parolă utilizând autentificarea RSA și DSA.
Continuați în același spirit și creați mai multe sesiuni noi și veți observa că fiecare breloc va "lega" la același proces de ssh-agent. Nu uitați că puteți, de asemenea, să "legați" scripturile și cron-urile de la procesele deja executate de agent ssh-agent. Pentru a utiliza comenzile ssh și scp din script-urile shell și cron, mai întâi, asigurați-vă că aceștia utilizează mai întâi fișierul dvs. ca sursă de informație
Apoi, toate comenzile ssh sau scp ulterioare vor putea detecta un ssh-agent care rulează deja și va stabili o conexiune fără parole securizată la fel cum o faci din shell.
Opțiuni pentru chei.
După ce ați configurat și executați cheia de chei, faceți dificultatea de a apela tasta --help pentru a vă familiariza cu toate opțiunile din linia de comandă a keychain-ului. Considerăm acum o particularitate: opțiunea - clară.
Dacă vă amintiți, în partea 1, am explicat că, folosind chei private necriptate este plină, deoarece permite cineva să fure cheia privată și să-l utilizați pentru a accesa conturile de la distanță de la orice sistem, fără nici o parolă. Ei bine, la Keychain și nu este vulnerabil din acest punct de vedere (pe măsură ce utilizați chei private criptate), încă în munca ei există un punct slab care este direct legată de faptul că Keychain face atât de ușor de a „face un caracter obligatoriu“ pentru a lucra proces constant ssh agent apartinand. M-am gândit, ce s-ar întâmpla dacă unii atacator poate calcula cumva parola sau expresie de acces și de a intra în sistemul meu local? Dacă el poate intra într-un fel sub numele meu, imediat Keychain se deschide accesul la cheile mele private decriptate, asta atacator ozvolit pentru a accesa cu ușurință toate celelalte conturi mele.
Opțiunea - Clear vă oferă opțiunea de a specifica pentru breloc. că ar trebui să ia în considerare fiecare nouă conexiune la contul dvs. ca o posibilă gaură de securitate, până când se va dovedi invers. Când rulați cheia cu opțiunea - clar. apoi, odată ce vă conectați, înainte de a începe să vă îndepliniți îndatoririle obișnuite, keychain-ul restabilește imediat toate cheile dvs. private din memoria cache a ssh-agentului. Astfel, dacă sunteți un intrus, keychain vă va cere să introduceți expresii cheie înainte de a vă acorda accesul la setările cheie existente în memoria cache. Deși acest lucru vă permite să creșteți gradul de protecție, dar face munca mai puțin incomodă și foarte asemănătoare cu a lucra direct cu omul ssh-agent fără un breloc. Și în acest caz, așa cum se întâmplă adesea, cineva poate face o alegere în favoarea unei mai mari siguranțe, iar cineva în favoarea confortului, dar nu împreună.