Cum să adăugați chei SSH la un VPS nou sau existent

Cheile SSH sunt perechi de chei criptografice — o cheie publică stocată pe server și o cheie privată păstrată pe mașina dvs. locală — care vă autentifică identitatea fără a transmite o parolă prin rețea. Când vă conectați, serverul emite o provocare criptografică pe care doar cheia dvs. privată o poate rezolva, acordând accesul dacă răspunsul este valid. Acest mecanism face autentificarea prin chei SSH fundamental mai rezistentă la atacurile de tip brute-force, credential stuffing și interceptarea man-in-the-middle decât orice schemă bazată pe parole.

Acest ghid acoperă procesul complet de generare, implementare și consolidare a autentificării prin chei SSH atât pe instanțe VPS noi, cât și pe cele existente — inclusiv cazuri limită, capcane legate de permisiuni și gestionarea mai multor chei pe care majoritatea tutorialelor le omit complet.

De ce cheile SSH sunt superioare din punct de vedere arhitectural față de parole

Autentificarea prin parolă trimite un secret (sau hash-ul acestuia) prin rețea și se bazează pe faptul că serverul stochează o acreditare verificabilă. Autentificarea SSH cu cheie publică nu expune niciodată cheia privată — nici în timpul generării, nici în timpul autentificării, niciodată. Cheia privată nu părăsește niciodată mașina dvs. locală.

Dincolo de securitatea brută, cheile SSH deblochează capabilități operaționale pe care parolele nu le pot oferi:

• Automatizare nesupravegheată — Fluxurile CI/CD, playbook-urile Ansible și sarcinile rsync programate prin cron necesită autentificare non-interactivă. Parolele fac acest lucru imposibil.
• Control granular al accesului — Fiecare intrare authorized_keys poate conține restricții command=, from= și no-pty, limitând exact ce are permisiunea să facă o anumită cheie.
• Auditabilitate — Cheile individuale pot fi revocate fără a schimba o parolă partajată și fără a perturba orice alt utilizator sau script.
• Rezistență la phishing — Nu există nicio parolă care să poată fi furată printr-o pagină de autentificare falsă.

Cerințe preliminare

Înainte de a continua, confirmați următoarele:

• Aveți un VPS funcțional sau sunteți în procesul de provizionare a unuia.
• Mașina dvs. locală rulează Linux, macOS sau Windows cu OpenSSH instalat (Windows 10/11 include OpenSSH implicit; verificați cu ssh -V).
• Aveți acces root sau sudo pe serverul țintă.
• Înțelegeți că pierderea cheii dvs. private fără o metodă alternativă de autentificare (acces la consolă, cheie de recuperare) vă poate bloca permanent accesul.

Alegerea algoritmului de cheie potrivit

Comanda originală ssh-keygen -t rsa -b 4096 este solidă, dar nu este singura opțiune. Înțelegerea compromisurilor vă ajută să faceți alegerea potrivită pentru mediul dvs.

Ed25519 este algoritmul recomandat pentru orice server care rulează OpenSSH 6.5 sau o versiune ulterioară (lansată în 2014). Utilizați RSA 4096 doar când vă conectați la sisteme vechi care nu suportă chei cu curbă eliptică.

Partea 1: Adăugarea cheilor SSH la un VPS nou

Multe panouri de control pentru găzduire vă permit să injectați o cheie publică în momentul provizionării, înainte ca instanța să pornească vreodată. Aceasta este cea mai curată abordare — cheia este integrată în imagine și este posibil ca autentificarea prin parolă să nu fie niciodată necesară.

Pasul 1: Generați perechea de chei SSH

Deschideți un terminal pe mașina dvs. locală. Generați o pereche de chei Ed25519:

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

Dacă aveți nevoie de RSA din motive de compatibilitate:

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

Când vi se solicită o locație pentru fișier, apăsați Enter pentru a accepta valoarea implicită (~/.ssh/id_ed25519 sau ~/.ssh/id_rsa). Când vi se solicită o frază de acces, setați una — aceasta criptează cheia privată pe disc, astfel încât, chiar dacă laptopul dvs. este furat, cheia este inutilizabilă fără fraza de acces. Agentul dvs. SSH (ssh-agent) va stoca în cache cheia decriptată în memorie, astfel încât să introduceți fraza de acces o singură dată pe sesiune.

Verificați fișierele generate:

ls -la ~/.ssh/

Veți vedea:

• id_ed25519 — cheia dvs. privată (permisiunile trebuie să fie 600; nu partajați niciodată acest fișier)
• id_ed25519.pub — cheia dvs. publică (poate fi copiată în siguranță oriunde)

Afișați cheia publică pentru a o copia:

cat ~/.ssh/id_ed25519.pub

Rezultatul arată astfel:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Copiați acest șir complet — îl veți lipi în panoul de control al găzduirii.

Pasul 2: Adăugați cheia publică în timpul provizionării VPS

Autentificați-vă în panoul de control al găzduirii. În timpul fluxului de creare a VPS-ului:

1. Selectați sistemul de operare (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 etc.).
2. Localizați secțiunea Cheie SSH sau Autentificare.
3. Lipiți conținutul complet al id_ed25519.pub în câmpul furnizat.
4. Completați configurația rămasă (plan, regiune, nume gazdă).

Odată ce VPS-ul pornește, sistemul de provizionare scrie automat cheia dvs. publică în /root/.ssh/authorized_keys. Nu este necesară autentificarea prin parolă.

Pasul 3: Conectați-vă la VPS-ul nou provizionat

ssh root@your_vps_ip

Dacă ați folosit un nume de fișier de cheie non-implicit, specificați-l explicit:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

O conexiune reușită fără solicitarea unei parole confirmă că cheia a fost injectată corect. Dacă ați setat o frază de acces, agentul dvs. SSH sau o solicitare de frază de acces o va gestiona local.

Partea 2: Adăugarea cheilor SSH la un VPS existent

Dacă VPS-ul dvs. rulează deja cu autentificare prin parolă, trebuie să implementați manual cheia publică. Acesta este un proces în două faze: copiați cheia, apoi consolidați opțional daemonul SSH.

Pasul 1: Generați o pereche de chei (dacă nu aveți una)

Urmați același proces ca la Pasul 1 din Partea 1 de mai sus. Dacă aveți deja o pereche de chei, recuperați cheia dvs. publică:

cat ~/.ssh/id_ed25519.pub

Pasul 2: Copiați cheia publică pe server

Metoda A — ssh-copy-id (Recomandată)

Utilitarul ssh-copy-id gestionează automat crearea directoarelor, adăugarea fișierelor și setarea permisiunilor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Introduceți parola când vi se solicită. Instrumentul adaugă cheia la ~/.ssh/authorized_keys pe serverul remote și setează permisiunile corecte. Aceasta este cea mai sigură metodă deoarece previne suprascrierea accidentală a cheilor existente.

Metoda B — Implementare manuală

Utilizați aceasta când ssh-copy-id nu este disponibil (de exemplu, în unele medii Windows sau rețele restricționate):

cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Acest pipeline unic este mai sigur decât deschiderea unui editor de text pe serverul remote deoarece adaugă în loc să suprascrie.

Metoda C — Manuală prin editor de text (Alternativă)

Autentificați-vă pe server cu parola dvs.:

ssh root@your_vps_ip

Creați directorul .ssh dacă nu există:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Deschideți authorized_keys într-un editor de text:

nano ~/.ssh/authorized_keys

Lipiți cheia dvs. publică pe o linie nouă. Salvați cu Ctrl+X, apoi Y, apoi Enter. Setați permisiunile:

chmod 600 ~/.ssh/authorized_keys

Închideți sesiunea:

exit

Pasul 3: Verificați autentificarea bazată pe cheie

Testați conexiunea înainte de a face orice alte modificări la daemonul SSH. Deschideți o nouă fereastră de terminal (nu închideți sesiunea existentă încă):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Dacă vă conectați fără solicitarea unei parole, cheia funcționează. Continuați cu pașii de consolidare de mai jos doar după confirmarea acestui lucru.

Capcană critică: Dacă dezactivați autentificarea prin parolă înainte de a verifica accesul prin cheie, iar implementarea cheii a eșuat din orice motiv, vă veți bloca accesul. Testați întotdeauna mai întâi.

Pasul 4: Consolidați configurația daemonului SSH

Odată ce accesul bazat pe cheie este confirmat, deschideți fișierul de configurare al daemonului SSH:

nano /etc/ssh/sshd_config

Aplicați următoarele setări:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Note cheie despre aceste directive:

• PermitRootLogin prohibit-password permite autentificarea root prin cheie, dar blochează autentificarea root prin parolă — un compromis mai bun decât PermitRootLogin no când încă configurați un utilizator sudo non-root.
• ChallengeResponseAuthentication no dezactivează autentificarea keyboard-interactive, care poate ocoli PasswordAuthentication no pe unele configurații PAM.
• Pe Ubuntu 22.04+, fișierul /etc/ssh/sshd_config.d/50-cloud-init.conf poate suprascrie setările dvs. Verificați-l și editați-l dacă este necesar.

Validați sintaxa configurației înainte de repornire:

sshd -t

Dacă nu sunt raportate erori, reporniți serviciul SSH:

systemctl restart sshd

Pe sistemele care utilizează ssh.service în loc de sshd.service:

systemctl restart ssh

Gestionarea mai multor chei SSH și utilizatori

Mediile din lumea reală implică rareori o singură cheie și un singur utilizator. Iată cum să gestionați scenarii mai complexe.

Adăugarea cheilor pentru mai mulți utilizatori

Fiecare cont de utilizator are propriul fișier ~/.ssh/authorized_keys. Pentru a adăuga o cheie pentru un utilizator non-root numit deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Pasul chown este adesea omis și cauzează eșecuri de autentificare — atât SELinux, cât și OpenSSH verifică că fișierul authorized_keys este deținut de utilizatorul care se autentifică.

Restricționarea a ceea ce poate face o cheie

Puteți prefixa orice linie din authorized_keys cu opțiuni pentru a-i limita capabilitățile. Acest lucru este deosebit de util pentru cheile de implementare sau automatizarea backup-urilor:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Această cheie poate rula doar rsync în modul daemon — nimic altceva.

Utilizarea ~/.ssh/config pentru conexiuni mai curate

În loc să tastați comenzi ssh lungi, definiți aliasuri de gazdă pe mașina dvs. locală:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

După salvarea acestuia în ~/.ssh/config, conectați-vă pur și simplu cu:

ssh myserver

Utilizarea ssh-agent pentru stocarea în cache a frazelor de acces

Dacă cheia dvs. privată are o frază de acces (ar trebui să aibă), adăugați-o la agent pentru a nu fi solicitat în mod repetat:

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

Pe macOS, adăugați --apple-use-keychain pentru a persista după reporniri:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Capcane comune și depanare

Problemă: Solicitarea parolei continuă după adăugarea cheii

Rulați conexiunea cu ieșire detaliată pentru a diagnostica:

ssh -vvv root@your_vps_ip

Căutați linii precum Offering public key și Server accepts key. Dacă cheia este oferită dar respinsă, problema este aproape întotdeauna legată de permisiunile fișierelor pe server.

Verificați permisiunile pe server:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Permisiuni necesare:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Directorul home ~/ — nu trebuie să fie accesibil pentru toți la scriere (755 sau 750)

Problemă: SELinux blochează autentificarea pe RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Problemă: Fișierul authorized_keys are terminații de linie Windows (CRLF)

Dacă ați editat fișierul pe Windows și l-ați transferat, terminațiile de linie pot fi corupte. Remediați cu:

sed -i 's/r//' ~/.ssh/authorized_keys

Problemă: Se oferă cheia greșită

Dacă aveți mai multe chei, specificați-o explicit pe cea corectă:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Sau configurați-o în ~/.ssh/config după cum s-a arătat mai sus.

Cheile SSH în contextul infrastructurii dvs. de găzduire

Autentificarea prin chei SSH nu este doar o problemă pentru un singur server — se scalează pe întreaga dvs. infrastructură. Dacă gestionați o flotă de servere dedicate, o abordare centralizată folosind instrumente precum Ansible, Puppet sau un manager de secrete (HashiCorp Vault, AWS Secrets Manager) pentru a distribui și rota cheile autorizate este esențială.

Pentru echipele care rulează aplicații web pe VPS cu cPanel, interfața SSH Access din cPanel, din secțiunea Security, oferă o interfață grafică pentru generarea și gestionarea perechilor de chei — utilă pentru dezvoltatorii care nu sunt confortabili cu linia de comandă, dar au nevoie de acces securizat.

Dacă rulați sarcini de lucru intensive GPU pe infrastructura de găzduire GPU, autentificarea prin chei SSH este deosebit de critică deoarece aceste instanțe rulează adesea sarcini de lungă durată, nesupravegheate. O acreditare compromisă pe un server GPU poate duce la costuri semnificative de calcul neautorizat, pe lângă expunerea datelor.

Combinarea consolidării SSH cu un certificat SSL valid pe orice servicii web care rulează pe același server închide simultan cei mai comuni doi vectori de atac — accesul neautentificat la shell și traficul HTTP necriptat.

Pentru proiectele care utilizează găzduire web partajată care necesită și acces SSH, verificați dacă furnizorul dvs. suportă injectarea cheilor SSH prin panoul de găzduire, deoarece mediile partajate restricționează adesea SSH la utilizatori specifici cu acces limitat la shell.

Rotația cheilor și gestionarea pe termen lung a cheilor

Cheile SSH nu expiră automat. Fără o politică de rotație, o cheie compromisă cu ani în urmă poate acorda în continuare acces. Stabiliți aceste practici:

• Rotiți cheile anual sau imediat la suspiciunea de compromitere.
• Auditați fișierele authorized_keys pe toate serverele în mod regulat. Eliminați cheile aparținând foștilor angajați sau serviciilor dezafectate.
• Utilizați chei separate per dispozitiv — nu copiați aceeași cheie privată pe mai multe laptopuri sau servere. Dacă un dispozitiv este pierdut, revocați doar acea cheie.
• Utilizați chei separate per rol — cheia dvs. de acces personal, cheia de implementare CI/CD și cheia de automatizare backup ar trebui să fie toate distincte.
• Documentați proprietatea cheilor — mențineți un registru care mapează fiecare amprentă de cheie publică la proprietarul, scopul și data de expirare ale acesteia.

Pentru a afișa amprenta unei chei în scopul auditării:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Listă de verificare pentru decizii tehnice

Utilizați această matrice înainte de a finaliza configurarea cheilor SSH:

• Algoritm: Utilizați Ed25519 cu excepția cazului în care vă conectați la sisteme mai vechi decât OpenSSH 6.5; utilizați RSA 4096 ca alternativă.
• Frază de acces: Setați întotdeauna una pe cheile private utilizate de oameni; cheile de serviciu utilizate de automatizare o pot omite dacă sunt stocate într-un manager de secrete.
• Metoda de implementare: Utilizați ssh-copy-id pentru configurări interactive; utilizați gestionarea configurației (Ansible, Puppet) pentru implementările în flotă.
• Verificarea permisiunilor: Confirmați 700 pe ~/.ssh/, 600 pe authorized_keys și proprietatea corectă înainte de a dezactiva autentificarea prin parolă.
• Testați înainte de blocare: Verificați întotdeauna autentificarea prin cheie într-o sesiune de terminal separată înainte de a seta PasswordAuthentication no.
• Validarea configurației daemonului: Rulați sshd -t înainte de a reporni serviciul SSH pentru a detecta erorile de sintaxă.
• Dezactivați autentificarea prin parolă: Setați PasswordAuthentication no și ChallengeResponseAuthentication no împreună — unul singur este insuficient pe sistemele cu PAM activat.
• Politica de autentificare root: Preferați PermitRootLogin prohibit-password față de PermitRootLogin yes; migrați la un utilizator sudo non-root și setați PermitRootLogin no ca stare finală consolidată.
• Rotația cheilor: Programați rotația anuală; revocați imediat la pierderea unui dispozitiv sau la schimbarea personalului.
• Audit: Rulați periodic grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys pentru a revizui toate cheile autorizate din sistem.

Întrebări frecvente

Pot adăuga mai multe chei SSH pe același server?

Da. Fiecare linie din ~/.ssh/authorized_keys reprezintă o cheie publică autorizată. Puteți adăuga câte chei aveți nevoie — câte una pe linie. Acest lucru permite mai multor administratori sau mai multor dispozitive să se autentifice independent, iar dvs. puteți revoca orice cheie individuală ștergând linia corespunzătoare fără a-i afecta pe ceilalți.

Ce se întâmplă dacă îmi pierd cheia privată după dezactivarea autentificării prin parolă?

Veți fi blocat din SSH. Recuperarea necesită accesarea serverului printr-o metodă out-of-band: consola web a furnizorului dvs. de găzduire, VNC sau un mediu de boot de recuperare. De acolo puteți reactiva autentificarea prin parolă sau adăuga o nouă cheie publică. De aceea este esențial să păstrați acreditările de acces la consolă în siguranță și separate.

Este Ed25519 suportat pe toate serverele?

Ed25519 necesită OpenSSH 6.5 sau o versiune ulterioară, lansată în ianuarie 2014. Orice server care rulează o distribuție Linux modernă (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+) îl suportă. Singurul scenariu care necesită RSA este conectarea la sisteme cu adevărat vechi sau dispozitive embedded cu versiuni OpenSSH depășite.

Adăugarea unei chei SSH dezactivează automat autentificarea prin parolă?

Nu. Adăugarea unei chei în authorized_keys activează autentificarea bazată pe cheie, dar nu dezactivează autentificarea prin parolă. Trebuie să setați explicit PasswordAuthentication no în /etc/ssh/sshd_config și să reporniți daemonul SSH pentru a impune accesul exclusiv prin cheie.

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

Tehnic da, dar nu este recomandat pentru mediile de producție. Utilizarea unei singure chei pe mai multe servere înseamnă că compromiterea unei chei private acordă acces la toate. Practica mai bună este să utilizați chei per dispozitiv (câte o cheie per stație de lucru sau laptop), astfel încât pierderea unui dispozitiv să necesite revocarea doar a acelei chei pe flota dvs. de servere, nu înlocuirea cheilor peste tot simultan.