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!
Conţinut
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 git@github.com: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 git@github.com
, 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 git@github.com: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 git@github.com:steve/raspberry-spy.git
Meci. De asemenea, puteți schimba config
a fi Host mygithub
și clonați utilizând URI git@mygithub: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 git@bitbucket-corporate:company/project.git
Host bitbucket-personal
HostName bitbucket.org
User git
IdentityFile ~/.ssh/id_rsa_personal
IdentitiesOnly yes
Acum puteți utiliza git clone git@bitbucket-personal: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:
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
#Cum #să #gestionați #mai #multe #chei #SSH
Cum să gestionați mai multe chei SSH