Cum să Creați Chei SSH cu OpenSSH pe macOS sau Linux

Autentificarea SSH bazată pe chei este metoda standard din industrie pentru securizarea accesului la distanță la server. În loc să transmită o parolă prin rețea, clientul dvs. își dovedește identitatea rezolvând o provocare criptografică la care poate răspunde doar deținătorul cheii private — serverul nu vede niciodată cheia privată în sine.

O pereche de chei SSH constă din două fișiere legate matematic: o cheie privată (stocată exclusiv pe mașina dvs. locală, niciodată partajată) și o cheie publică (implementată pe fiecare server la care trebuie să accesați). Când inițiați o conexiune, OpenSSH folosește un handshake de tip provocare-răspuns pentru a verifica că cheia dvs. privată corespunde cheii publice de pe server, acordând acces fără o solicitare de parolă.

De ce cheile SSH sunt strict superioare autentificării prin parolă

Parolele sunt vulnerabile la atacuri de tip brute-force, credential stuffing, phishing și interceptare pe rețele configurate defectuos. Cheile SSH elimină simultan fiecare dintre acești vectori de atac.

• Putere criptografică: O cheie RSA de 4096 de biți sau o cheie Ed25519 este imposibil de spart prin brute-force cu hardware-ul actual.
• Niciun secret transmis prin rețea: Cheia privată nu părăsește niciodată mașina dvs. Protocolul de autentificare dovedește posesia fără dezvăluire.
• Pregătit pentru automatizare: Pipeline-urile CI/CD, playbook-urile Ansible, joburile rsync și backup-urile bazate pe cron necesită autentificare non-interactivă. Cheile SSH fac acest lucru posibil fără a încorpora parole în text simplu în scripturi.
• Auditabilitate: Fiecare pereche de chei poate fi identificată în mod unic prin amprenta sa, facilitând revocarea unei singure chei compromise fără a roti acreditările peste tot.
• Compatibilitate cu ACL-urile authorized_keys: Puteți restricționa o cheie publică specifică să ruleze doar o singură comandă, să o legați de un IP sursă sau să preveniți redirecționarea porturilor — controale pe care autentificarea prin parolă nu le poate replica.

Dacă gestionați un VPS sau un server dedicat, dezactivarea completă a autentificării prin parolă și impunerea autentificării exclusiv prin chei este unul dintre cei mai eficienți pași de întărire a securității pe care îi puteți face.

Alegerea algoritmului de cheie potrivit

Documentația originală OpenSSH și majoritatea tutorialelor vechi folosesc implicit RSA. Domeniul a evoluat. Iată o comparație precisă a fiecărui algoritm pe care ssh-keygen îl suportă astăzi:

Ed25519 este implicit-ul corect în 2024. Produce chei mai scurte, semnează mai rapid, iar dimensiunea fixă a cheii elimină riscul de a genera accidental o cheie subdimensionată. RSA la 4096 de biți rămâne acceptabil pentru mediile care trebuie să interopereze cu sisteme mai vechi anterioare suportului Ed25519 (OpenSSH < 6.5, lansat în 2014).

Cerințe preliminare

• O stație de lucru macOS sau Linux cu OpenSSH instalat. Ambele sisteme de operare includ OpenSSH implicit. Verificați cu:

ssh -V

• Acces în rețea la un server la distanță unde aveți un cont (root sau fără privilegii).
• Familiarizare de bază cu un terminal.

Pe distribuțiile Linux care includ o instalare minimă (Alpine, unele instalări Debian netinstall), instalați instrumentele client cu:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Pasul 1: Deschideți un terminal

macOS: Apăsați Cmd + Space, tastați Terminal și apăsați Enter. Alternativ, navigați la Applications > Utilities > Terminal. Utilizatorii avansați pot folosi iTerm2 sau terminalul integrat din VS Code.

Linux: Apăsați Ctrl + Alt + T pe majoritatea mediilor desktop, sau lansați emulatorul de terminal al distribuției dvs. din meniul de aplicații.

Pasul 2: Generați perechea de chei SSH

Generarea unei chei Ed25519 (Recomandat)

ssh-keygen -t ed25519 -C "your_email@example.com"

Flag-ul -C adaugă un comentariu lizibil de om la cheia publică. Folosiți adresa dvs. de email, un hostname sau o etichetă descriptivă precum "deploy-key-prod" — nu are nicio funcție criptografică, dar este de neprețuit la auditarea fișierelor authorized_keys care acumulează zeci de intrări.

Generarea unei chei RSA (Compatibilitate cu sisteme vechi)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Folosiți -b 4096 în mod explicit. Valoarea implicită istorică de 2048 de biți este încă acceptabilă din punct de vedere tehnic, dar oferă o marjă mai mică față de progresele viitoare în algoritmii de factorizare. Nu folosiți niciodată -b 1024 sau -b 2048 pentru chei noi dacă 4096 este disponibil.

Generarea unei chei cu nume specific pentru un anumit host

Când gestionați mai multe servere sau roluri, folosiți fișiere de chei distincte în loc să reutilizați o singură cheie peste tot. O cheie compromisă afectează astfel doar sistemele pe care a fost implementată:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Pasul 3: Alegeți o locație de stocare

După rularea ssh-keygen, veți vedea:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Apăsați Enter pentru a accepta locația implicită (~/.ssh/id_ed25519 pentru Ed25519, ~/.ssh/id_rsa pentru RSA), sau tastați o cale personalizată. Locația implicită este potrivită pentru o singură cheie de uz general. Pentru cheile specifice unui rol, specificați întotdeauna un nume de fișier descriptiv, așa cum s-a arătat în pasul anterior.

Notă critică privind permisiunile fișierelor: Directorul ~/.ssh/ trebuie să aibă modul 700 și fișierele cu chei private trebuie să aibă modul 600. OpenSSH va refuza să folosească chei cu permisiuni prea permisive și va afișa un avertisment. Dacă copiați vreodată chei între mașini, verificați imediat permisiunile:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Pasul 4: Setați o frază de acces

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

O frază de acces criptează fișierul cheii private de pe disc folosind AES-256-CBC (în OpenSSH modern). Dacă un atacator obține fișierul dvs. cu cheia privată — printr-un laptop furat, un backup compromis sau un snapshot cloud configurat greșit — o frază de acces puternică este ultima linie de apărare care îl împiedică să o folosească.

Când să omiteți fraza de acces: Conturile de serviciu automatizate (pipeline-uri de implementare, agenți de backup) care rulează nesupravegheat au nevoie în mod legitim de chei fără frază de acces. În acest caz, restricționați permisiunile cheii pe partea serverului folosind opțiunile authorized_keys (consultați secțiunea avansată de mai jos) și stocați cheia privată într-un manager de secrete, nu pe un sistem de fișiere partajat.

După confirmarea frazei de acces, OpenSSH afișează amprenta cheii și o imagine randomart:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Notați amprenta. O veți folosi pentru a verifica identitatea cheii la auditarea serverelor.

Pasul 5: Copiați cheia publică pe serverul la distanță

Metoda 1: ssh-copy-id (Cea mai rapidă)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Flag-ul -i specifică explicit ce cheie publică să copieze, împiedicând ssh-copy-id să încarce fiecare cheie din agentul dvs. Vi se va solicita parola serverului o singură dată. Instrumentul gestionează automat crearea directoarelor, adăugarea în fișier și setarea permisiunilor.

Metoda 2: Implementare manuală (Când ssh-copy-id nu este disponibil)

Aceasta este abordarea corectă când sistemul la distanță este Windows, un dispozitiv de rețea sau un container fără ssh-copy-id în cale.

Mai întâi, afișați cheia dvs. publică:

cat ~/.ssh/id_ed25519.pub

Copiați întregul output — este o singură linie care începe cu ssh-ed25519 (sau ssh-rsa). Apoi conectați-vă la server și adăugați-o:

ssh user@your-server.com

Odată conectat:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Capcană frecventă: Folosirea > în loc de >> suprascrie întregul fișier authorized_keys, blocând accesul oricărei alte chei. Folosiți întotdeauna >> pentru a adăuga.

Metoda 3: Pipe prin SSH într-o singură comandă

Dacă aveți deja acces prin parolă și doriți să implementați fără a vă conecta interactiv:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Pasul 6: Testați conexiunea

ssh -i ~/.ssh/id_ed25519 user@your-server.com

O conexiune reușită fără o solicitare de parolă (sau cu doar o solicitare de frază de acces pentru cheia dvs. locală) confirmă că configurarea este corectă. Dacă conexiunea eșuează, rulați cu output detaliat pentru a diagnostica:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Flag-ul -vvv afișează jurnalul complet al negocierii, arătând exact ce cheie a fost oferită, dacă serverul a acceptat-o și unde a eșuat handshake-ul.

Pasul 7: Configurați ~/.ssh/config pentru profiluri de host persistente

Tastarea completă a ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 de fiecare dată este predispusă la erori și lentă. Fișierul de configurare al clientului SSH elimină acest lucru:

nano ~/.ssh/config

Adăugați un bloc de host:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Acum conectați-vă pur și simplu cu:

ssh prod-web

Acest model se scalează curat la zeci de servere și este esențial pentru orice inginer care gestionează infrastructura la scară. Directiva ServerAliveInterval 60 trimite un pachet keepalive la fiecare 60 de secunde, prevenind abandonarea conexiunilor inactive de către firewall-uri — o frustrare frecventă la furnizorii de cloud.

Gestionarea mai multor chei cu agentul SSH

Agentul SSH păstrează cheile private decriptate în memorie pe durata sesiunii dvs., astfel încât introduceți fraza de acces o singură dată, nu la fiecare conexiune.

Porniți agentul și adăugați o cheie:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Pe macOS, puteți persista cheile între reporniri adăugând următoarele în ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Directiva UseKeychain yes se integrează cu macOS Keychain, stocând fraza de acces în siguranță astfel încât să supraviețuiască repornirilor sistemului.

Listați toate cheile încărcate în prezent în agent:

ssh-add -l

Eliminați o cheie specifică din agent:

ssh-add -d ~/.ssh/id_ed25519

Avansat: Restricționarea cheilor în authorized_keys

Fișierul authorized_keys suportă opțiuni per-cheie care reduc dramatic raza de impact a unei chei compromise. Acestea sunt plasate înaintea tipului de cheie pe aceeași linie:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Aceste opțiuni sunt deosebit de valoroase pentru cheile de implementare pe servere dedicate unde o singură cheie CI/CD compromisă nu ar trebui să acorde acces complet la shell.

Întărirea daemonului SSH după implementarea cheilor

Odată ce autentificarea bazată pe chei funcționează, dezactivați complet autentificarea prin parolă pe server. Editați /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Setați următoarele directive:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Reîncărcați daemonul fără a deconecta sesiunea curentă:

sudo systemctl reload sshd

Nu închideți sesiunea SSH existentă înainte de a testa o nouă conexiune într-un terminal separat. O configurare greșită care vă blochează accesul poate fi remediată de la consolă, dar este perturbatoare și evitabilă.

Pentru serverele care rulează medii cPanel VPS, rețineți că unele versiuni cPanel gestionează propria configurație SSH. Verificați că modificările sshd_config persistă după actualizările cPanel verificând /etc/ssh/sshd_config.d/ pentru fișiere de suprasciere.

Rotirea și revocarea cheilor SSH

Rotirea cheilor este o practică de igienă a securității care limitează fereastra de expunere dacă o cheie este compromisă în mod silențios. Un program practic de rotire este la fiecare 12 luni pentru cheile personale și la fiecare 90 de zile pentru cheile conturilor de serviciu.

Pentru a revoca o cheie: Eliminați linia sa din ~/.ssh/authorized_keys pe fiecare server unde a fost implementată. Nu există niciun mecanism central de revocare în OpenSSH standard — de aceea menținerea unui inventar al locurilor unde este implementată fiecare amprentă de cheie este importantă.

Pentru a roti o cheie:

1. Generați o nouă pereche de chei.
2. Implementați noua cheie publică pe toate serverele țintă.
3. Testați conectivitatea cu noua cheie.
4. Eliminați cheia publică veche din toate fișierele authorized_keys.
5. Ștergeți sau arhivați cheia privată veche local.

Pentru mediile cu hosting VPS în mai multe regiuni, un instrument de gestionare a configurației precum Ansible este soluția practică pentru propagarea rotirilor de chei la scară.

Transferul cheilor între mașini

Când configurați o nouă stație de lucru, trebuie să migrați cheile private existente în loc să generați altele noi (ceea ce ar necesita reimplementarea cheilor publice peste tot).

Copiați cheia privată în siguranță folosind scp sau rsync prin SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Alternativ, folosiți un stick USB criptat sau un manager de parole care suportă stocarea cheilor SSH (1Password, Bitwarden și HashiCorp Vault suportă toate acest lucru). Nu trimiteți niciodată chei private prin email și nu le stocați în spații de stocare cloud necriptate.

După transfer, verificați imediat permisiunile pe noua mașină:

chmod 600 ~/.ssh/id_ed25519

Verificarea amprentei cheii de host a unui server

Prima dată când vă conectați la un server, OpenSSH prezintă amprenta cheii de host a serverului și vă cere să o confirmați:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Nu tastați niciodată yes orb. Obțineți amprenta așteptată printr-un canal out-of-band — panoul de control al furnizorului dvs. de hosting, un coleg care a provizionat serverul sau output-ul consolei serverului. Acest pas previne atacurile man-in-the-middle. Pentru mediile de hosting partajat, amprenta așteptată este de obicei listată în panoul de control sub setările de acces SSH.

Odată acceptată, amprenta este stocată în ~/.ssh/known_hosts. Dacă amprenta se schimbă în mod neașteptat la o conexiune ulterioară, OpenSSH va refuza să se conecteze și va afișa un avertisment — tratați acest lucru ca un eveniment de securitate serios care necesită investigare înainte de a continua.

Matrice de decizie și listă de verificare tehnică

Folosiți această listă de verificare înainte de a considera configurarea cheilor SSH pregătită pentru producție:

• [ ] Algoritmul cheii este Ed25519 (sau RSA 4096 pentru compatibilitate cu sisteme vechi) — DSA și ECDSA 256 nu sunt acceptabile pentru implementări noi
• [ ] Permisiunile fișierului cu cheia privată sunt 600; permisiunile directorului ~/.ssh/ sunt 700
• [ ] O frază de acces puternică este setată pe toate cheile utilizatorilor interactivi
• [ ] Cheile conturilor de serviciu fără fraze de acces sunt restricționate prin opțiunile authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no este setat în /etc/ssh/sshd_config pe toate serverele
• [ ] PermitRootLogin prohibit-password sau PermitRootLogin no este impus
• [ ] Amprentele cheilor de host ale serverului au fost verificate out-of-band
• [ ] Există un inventar al cheilor care mapează fiecare amprentă la serverele unde este implementată
• [ ] Programul de rotire a cheilor este definit și calendarizat
• [ ] Blocurile de host ~/.ssh/config sunt configurate pentru a evita utilizarea manuală a flag-ului -i
• [ ] Agentul SSH este folosit pentru a evita introducerea repetată a frazei de acces în timpul sesiunilor de lucru
• [ ] Intrările known_hosts sunt revizuite periodic pentru intrări vechi sau neașteptate

Întrebări frecvente

Care este diferența dintre cheile SSH Ed25519 și RSA?

Ed25519 folosește criptografia pe curbe eliptice cu o cheie fixă de 256 de biți care oferă aproximativ 128 de biți de securitate, semnează operațiunile mai rapid decât RSA și produce șiruri de chei mai scurte. RSA la 4096 de biți oferă securitate comparabilă, dar este mai lent și generează material de cheie mai mare. Folosiți Ed25519 pentru toate cheile noi, cu excepția cazului în care trebuie să vă conectați la un sistem care rulează OpenSSH mai vechi decât versiunea 6.5.

Pot folosi aceeași pereche de chei SSH pentru mai multe servere?

Da, tehnic. Cu toate acestea, cea mai bună practică este să folosiți perechi de chei distincte per rol sau mediu (acces de la stația de lucru personală, implementare CI/CD, întreținere baze de date). Acest lucru limitează impactul unei singure chei compromise și face revocarea simplă fără a perturba sistemele fără legătură.

Ce se întâmplă dacă îmi pierd cheia privată?

Pierdeți capacitatea de a vă autentifica folosind acea pereche de chei. Cheia publică de pe server devine inutilă. Trebuie să accesați serverul printr-o metodă alternativă — acces la consolă, o cheie secundară sau accesul de urgență al furnizorului dvs. de hosting — apoi să eliminați cheia publică orfană din authorized_keys și să implementați o nouă pereche de chei.

De ce SSH solicită în continuare o parolă după ce am copiat cheia publică?

Cele mai frecvente cauze sunt: permisiuni incorecte pe ~/.ssh/ (trebuie să fie 700) sau ~/.ssh/authorized_keys (trebuie să fie 600) pe server; directorul home în sine este accesibil pentru toți; SELinux sau AppArmor blochează accesul la directorul .ssh; sau PubkeyAuthentication no este setat în /etc/ssh/sshd_config. Rulați ssh -vvv pentru a identifica exact ce metodă de autentificare este încercată și respinsă.

Cum elimin o cheie SSH de pe un server la care nu mai am acces?

Dacă nu aveți nicio altă metodă de autentificare, contactați echipa de suport a furnizorului dvs. de hosting sau folosiți accesul out-of-band la consolă (disponibil pentru clienții VPS și server dedicat) pentru a vă conecta și a edita ~/.ssh/authorized_keys direct. De aceea menținerea acreditărilor de acces la consolă separat de cheile SSH este o cerință operațională non-negociabilă.