Este sigur să spunem că majoritatea dezvoltatorilor din sfera web au întâlnit la un moment dat SSH. SSH este unul dintre cele mai utilizate protocoale pentru schimbul sigur de date. Utilizați SSH pentru conectarea la servere la distanță, care include, de asemenea, gestionarea codului dvs. utilizând Git și sincronizarea cu depozite la distanță.

Chiar dacă este considerată o practică bună să aveți o pereche de chei private-publice pe dispozitiv, uneori trebuie să utilizați mai multe chei și / sau aveți nume de chei neortodoxe.

S-ar putea să utilizați o pereche de chei SSH pentru a lucra la proiectele interne ale companiei dvs., dar s-ar putea să utilizați o altă cheie pentru accesarea serverelor unor clienți corporativi. S-ar putea chiar să utilizați o altă cheie pentru accesarea propriului server privat.

Gestionarea cheilor SSH poate deveni greoaie de îndată ce trebuie să utilizați oa doua cheie. Sper că acest articol va fi de ajutor pentru oricine are probleme cu gestionarea cheilor SSH.

Presupun că cititorul are cunoștințe de bază despre Git și SSH. Majoritatea exemplelor din articol vor folosi Git. Desigur, toate acestea se vor aplica oricărei alte comunicări SSH. Acestea fiind spuse, există câteva trucuri specifice Git incluse.

Închideți-ne, iată-ne!

Gestionarea unei chei SSH

Mai întâi, permiteți-ne să vedem cum ar putea arăta fluxul dvs. de lucru înainte de a avea mai multe chei de care să vă faceți griji.

Aveți o cheie privată stocată în ~/.ssh/id_rsa cu o cheie publică corespunzătoare ~/.ssh/id_rsa.pub.

Să ne imaginăm că doriți să împingeți / trageți modificări de cod către / de la un server Git la distanță – spuneți GitHub, de ce nu. Pentru a face acest lucru, trebuie mai întâi să adăugați cheia dvs. publică la GitHub.

Nu voi trece peste acel pas, ar trebui să fie suficient de ușor să aflăm cum să fac asta. De asemenea, am presupus că numele tău este Steve și că lucrezi la un proiect de top-secret care folosește Raspberry Pies pentru a adulmeca traficul de rețea.

Pentru a începe munca, trebuie să clonați un depozit git folosind SSH:

git clone [email protected]:steve/raspberry-spy.git

În acest moment, GitHub va spune: „Ei, acesta este un depozit privat! Trebuie să criptăm traficul folosind această cheie publică pe care o am aici și cheia dvs. privată. ”

Ați adăugat cheia publică la profilul dvs. pe GitHub, dar SSH trebuie să-și dea seama cum se află cheia dvs. privată corespunzătoare.

Deoarece nu avem nici o idee despre ce cheie privată ar trebui să fie folosită atunci când SSH-ing în [email protected], Clientul SSH încearcă să găsească o cheie în locația implicită, care este ~/.ssh/id_rsa – este cea mai bună presupunere a lui. Dacă nu există fișier în acea locație, veți primi o eroare:

Cloning into 'raspberry-spy'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Daca ai niste cheie privată stocată în fișier ~/.ssh/id_rsa, Clientul SSH va folosi acea cheie privată pentru criptarea comunicării. Dacă acea cheie este introdusă cu parolă (așa cum ar trebui să fie), vi se va solicita o parolă, astfel:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

Dacă introduceți fraza de acces corectă și dacă acea cheie privată este într-adevăr cea care corespunde cheii publice pe care ați atașat-o la profilul dvs., toate vor merge bine și depozitul va fi clonat cu succes.

Dar dacă ai numi cheia altfel (ex. ~/.ssh/_id_rsa)? Clientul SSH nu va putea determina unde este stocată cheia privată. Veți obține același lucru Permission denied ... eroare ca până acum.

Dacă doriți să utilizați o cheie privată pe care ați numit-o diferit, trebuie să o adăugați manual:

ssh-add ~/.ssh/_id_rsa

După introducerea expresiei de acces, puteți verifica dacă a fost adăugată cheia ssh-agent (Client SSH) prin executare ssh-add -l. Această comandă va lista toate cheile care sunt disponibile în prezent pentru clientul SSH.

Dacă încercați să clonați acum depozitul, acesta va avea succes.

Până acum, bine?

Dacă sunteți cu ochii dornici, s-ar putea să începeți să observați câteva probleme potențiale.

În primul rând, dacă reporniți computerul, ssh-agent va reporni și va trebui să adăugați cheile care nu sunt denumite implicit folosind ssh-add din nou, tastând parole și toate lucrurile acelea plictisitoare.

Putem automat să adăugăm chei sau să specificăm cumva ce cheie să folosim atunci când accesăm anumite servere?

Putem cumva să salvăm parolele, astfel încât să nu trebuiască să le introducem de fiecare dată? Dacă ar exista ceva de genul a breloc pentru salvarea cheilor SSH protejate prin parolă?.

Fii sigur, există răspunsuri la toate aceste întrebări.

Intrați, SSH config

După cum se dovedește, Fișier de configurare SSH este un lucru, un lucru care ne poate ajuta. Este un fișier de configurare per utilizator pentru comunicarea SSH. Creați un fișier nou: ~/.ssh/config și deschideți-l pentru editare.

Gestionarea cheilor SSH personalizate

Primul lucru pe care îl vom rezolva folosind acest lucru config fișierul evită să adăugați chei SSH cu nume personalizate folosind ssh-add. Presupunând că se numește cheia SSH ~/.ssh/_id_rsa, adăugați următoarele la config fişier:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/_id_rsa
  IdentitiesOnly yes

Acum asigurați-vă că ~/.ssh/_id_rsa nu este în ssh-agent prin executarea ssh-add -D. Această comandă va elimina toate cheile din activul curent ssh-agent sesiune. Sesiunea se resetează de fiecare dată când vă deconectați sau reporniți (sau dacă ucideți ssh-agent proces manual). Putem „simula” repornirea executând comanda menționată.

Dacă încercați acum să clonați depozitul GitHub acum, va fi la fel ca și când am adăuga cheia manual (așa cum am făcut înainte). Vi se va solicita parola:

git clone [email protected]:steve/raspberry-spy.git
Cloning into 'raspberry-spy'...
Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

Veți observa că cheia pentru a cărei parolă ni se solicită este aceeași cheie pe care am specificat-o în config fişier. După introducerea parolei corecte a cheii SSH, depozitul va fi clonat cu succes.

Notă: dacă, după clonarea cu succes, încercați git pull, vi se va solicita din nou parola. Vom rezolva asta mai târziu.

Este important ca Host github.com din config și github.com din URI [email protected]:steve/raspberry-spy.git Meci. De asemenea, puteți schimba config a fi Host mygithub și clonați utilizând URI [email protected]:steve/raspberry-spy.git.

Aceasta deschide porțile. Pe măsură ce înroșești acest lucru, mintea ta aleargă și se gândește la modul în care toate problemele tale cu tastele SSH s-au încheiat. Iată câteva exemple utile de configurare:

Host bitbucket-corporate
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_corp
        IdentitiesOnly yes

Acum puteți utiliza git clone [email protected]:company/project.git

Host bitbucket-personal
        HostName bitbucket.org
        User git
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes

Acum puteți utiliza git clone [email protected]:steve/other-pi-project.git

Host myserver
        HostName ssh.steve.com
        Port 1111
        IdentityFile ~/.ssh/id_rsa_personal
        IdentitiesOnly yes
        User steve
        IdentitiesOnly yes

Acum puteți introduce SSH pe serverul dvs. folosind ssh myserver. Cat de tare e asta? Nu este nevoie să introduceți manual portul și numele de utilizator de fiecare dată când executați ssh comanda.

Bonus: Setări pentru fiecare depozit

De asemenea, puteți defini ce cheie specifică trebuie utilizată pentru anumite depozite, anulând orice în SSH config. Comanda SSH specifică poate fi definită prin setare sshCommand sub core în <project>/.git/config. Exemplu:

[core]
        sshCommand = ssh -i ~/.ssh/id_rsa_corp

Acest lucru este posibil cu git 2.10 sau o versiune ulterioară. De asemenea, puteți utiliza această comandă pentru a evita editarea manuală a fișierului:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Administrarea parolei

Ultima piesă a puzzle-ului este gestionarea parolelor. Vrem să evităm să introducem parola de fiecare dată când se inițiază conexiunea SSH. Pentru a face acest lucru, putem utiliza software-ul de gestionare a brelocurilor care vine cu MacOS și diverse distribuții Linux.

Începeți prin adăugarea cheii la breloc prin trecere -K opțiune la ssh-add comanda:

ssh-add -K ~/.ssh/id_rsa_whatever

Acum puteți vedea cheia SSH în breloc. Pe MacOS arată cam așa:

Acces la cheie

Dacă scoateți cheile din ssh-agent prin intermediul ssh-add -D (acest lucru se va întâmpla când reporniți computerul, așa cum am menționat anterior) și încercați SSH-ing, vi se va solicita din nou parola. De ce? Tocmai am adăugat cheia brelocului. Dacă bifați din nou Accesul la breloc, veți observa că cheia pe care ați adăugat-o folosind ssh-add -K este încă în breloc. Ciudat, nu?

Se pare că mai este încă un cerc prin care sări. Deschideți SSH-ul config fișier și adăugați următoarele:

Host *
  AddKeysToAgent yes
  UseKeychain yes

Acum, SSH va căuta cheia în breloc și, dacă o găsește, nu vi se va solicita parola. Cheia va fi, de asemenea, adăugată la ssh-agent. Pe MacOS, acest lucru va funcționa pe MacOS Sierra 10.12.2 sau o versiune ulterioară. Pe Linux poți folosi ceva de genul gnome-keyring și ar putea funcționa chiar și fără această ultimă modificare a SSH config. În ceea ce privește Windows – cine știe, nu?

Sper că cineva a găsit acest lucru util. Acum du-te și configurează-ți SSH-ul config fişier!

Aflați mai multe despre SSH:

  • Ghidul final pentru cheile SSH
  • O introducere de sus în jos a SSH