Cum să încarci o cheie publică SSH pe un VPS existent

O cheie publică SSH este o acreditare criptografică stocată în ~/.ssh/authorized_keys pe un server la distanță, care acordă acces oricărui client care deține cheia privată corespunzătoare — fără a transmite o parolă prin rețea. Încărcarea cheii publice pe un VPS existent înlocuiește sau completează autentificarea bazată pe parolă cu criptografie asimetrică, eliminând suprafața de atac exploatată de campaniile de tip brute-force și credential-stuffing.

Acest ghid acoperă fiecare etapă a procesului: generarea cheilor, metodele de încărcare manuală și automată, consolidarea permisiunilor, configurarea sshd_config, gestionarea mai multor chei și modurile comune de eșec care îi surprind chiar și pe administratorii experimentați.

De ce autentificarea prin chei SSH depășește parolele

Înainte de a introduce o singură comandă, merită să înțelegem mecanica criptografică. Când vă autentificați cu o pereche de chei, serverul emite o provocare criptată cu cheia dvs. publică. Doar deținătorul cheii private corespunzătoare poate decripta și semna răspunsul. Niciun secret nu este transmis vreodată — comparați aceasta cu autentificarea prin parolă, unde acreditarea în sine călătorește prin rețea (chiar dacă este învelită în TLS).

Concluzia practică: în orice mediu de VPS Hosting expus internetului public, cheile SSH nu sunt o măsură opțională de securizare — ele reprezintă standardul de bază.

Cerințe preliminare

• Un VPS existent accesibil prin SSH (autentificarea prin parolă sau prin cheie existentă funcționează în prezent)
• O mașină locală care rulează Linux, macOS sau Windows cu OpenSSH sau PuTTY
• Privilegii suficiente pe VPS pentru a scrie în directorul home al utilizatorului țintă
• Familiaritate de bază cu un terminal și un editor de text precum nano sau vim

Pasul 1: Generați o pereche de chei SSH

Dacă aveți deja o pereche de chei la ~/.ssh/id_ed25519 sau ~/.ssh/id_rsa, treceți mai departe. Altfel, generați una acum.

Alegerea algoritmului potrivit

Ed25519 este standardul modern. Utilizați RSA 4096 doar când vă conectați la servere vechi care nu suportă Ed25519.

Generați o pereche de chei Ed25519:

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

Generați o pereche de chei RSA 4096 (sisteme vechi):

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

În timpul generării cheii veți fi solicitat să introduceți o cale de salvare și o frază de acces opțională. Acceptarea căii implicite (~/.ssh/id_ed25519) este în regulă pentru majoritatea utilizatorilor. Setați întotdeauna o frază de acces — aceasta criptează cheia privată de pe disc folosind AES-256, astfel încât un laptop furat nu înseamnă automat un server compromis.

Procesul produce două fișiere:

~/.ssh/id_ed25519 — cheia dvs. privată. Nu o partajați niciodată, nu o copiați pe un server, nu o includeți în controlul versiunilor.
~/.ssh/id_ed25519.pub — cheia dvs. publică. Aceasta poate fi distribuită liber.

Afișați cheia publică pentru a o putea copia:
cat ~/.ssh/id_ed25519.pub
Rezultatul va arăta similar cu:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Copiați întregul șir de pe o singură linie, inclusiv prefixul algoritmului și comentariul de la sfârșit.
Pasul 2: Conectați-vă la VPS-ul dvs.
Conectați-vă la VPS folosind metoda de autentificare curentă:
ssh root@your_vps_ip
Înlocuiți your_vps_ip cu adresa IPv4 sau IPv6 reală a serverului dvs. Dacă gestionați un cont de utilizator non-root, substituiți root cu numele de utilizator corespunzător. Pe Servere Dedicate unde puteți avea mai multe conturi de utilizator, preferați întotdeauna implementarea cheilor pentru un utilizator non-root și utilizați sudo pentru escaladarea privilegiilor.
Pasul 3: Pregătiți directorul .ssh
Odată autentificat, verificați sau creați directorul .ssh pentru utilizatorul țintă:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Permisiunea 700 (rwx------) este obligatorie. OpenSSH va refuza în tăcere să utilizeze authorized_keys dacă directorul .ssh este accesibil la scriere de grup sau de toți utilizatorii. Aceasta este una dintre cele mai frecvente cauze pentru care autentificarea prin cheie eșuează după o configurare altfel corectă.
Pasul 4: Adăugați cheia publică în authorized_keys
Metoda A: Lipire manuală (Universală)
Deschideți sau creați fișierul authorized_keys:
nano ~/.ssh/authorized_keys
Lipiți cheia dvs. publică pe o linie nouă. Fiecare linie din acest fișier reprezintă o cheie autorizată. Salvați cu Ctrl+X, apoi Y, apoi Enter.
Setați permisiunile corecte:
chmod 600 ~/.ssh/authorized_keys
Permisiunea 600 (rw-------) asigură că doar proprietarul fișierului îl poate citi sau scrie. OpenSSH aplică acest lucru strict.
Metoda B: ssh-copy-id (Recomandat pentru viteză)
Dacă mașina dvs. locală are ssh-copy-id disponibil (standard pe Linux și macOS), această singură comandă gestionează automat crearea directorului, adăugarea cheii și setarea permisiunilor:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Vi se va solicita parola SSH curentă o singură dată. După aceea, autentificarea bazată pe cheie este activă. Indicatorul -i specifică explicit care cheie publică să fie încărcată, prevenind încărcările accidentale ale cheii greșite.
Metoda C: Comandă unică prin cat și pipe (Scriptabilă)
Utilă în pipeline-uri de automatizare sau când ssh-copy-id nu este disponibil:
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"
Această abordare este sigură din punct de vedere idempotent în sensul că adaugă în loc să suprascrie, păstrând orice chei autorizate existente.
Pasul 5: Verificați proprietatea corectă a fișierelor
O capcană frecvent trecută cu vederea: dacă ați creat directorul .ssh sau fișierul authorized_keys ca root în timp ce configurați contul altui utilizator, proprietatea va fi greșită și SSH va respinge cheia în tăcere.
Verificați proprietatea:
ls -la ~/.ssh/
Rezultatul ar trebui să arate numele de utilizator țintă atât ca proprietar, cât și ca grup pentru ambele, directorul și fișierul:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Dacă proprietatea este incorectă, corectați-o (rulați ca root):
chown -R alice:alice /home/alice/.ssh
Pasul 6: Testați autentificarea SSH prin cheie
Ieșiți din sesiunea curentă:
exit
Reconectați-vă folosind specificarea explicită a cheii pentru a confirma configurarea:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Dacă autentificarea reușește fără o solicitare de parolă (sau solicită doar fraza de acces a cheii locale), configurarea este corectă. Dacă solicită în continuare parola serverului, continuați cu secțiunea de depanare de mai jos.
Pasul 7: Consolidați configurația daemonului SSH
Odată ce autentificarea bazată pe cheie este confirmată că funcționează, dezactivați autentificarea prin parolă pentru a elimina complet vectorul de atac brute-force prin parolă.
Deschideți fișierul de configurare al daemonului SSH:
nano /etc/ssh/sshd_config
Localizați și setați următoarele directive. Dacă o linie este comentată cu #, eliminați # și setați valoarea:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
O notă despre PermitRootLogin prohibit-password: această setare permite autentificarea root exclusiv prin cheie, blocând accesul root bazat pe parolă, permițând în același timp sesiunile root autentificate prin cheie. Pentru securizare maximă, setați-o la no și utilizați un utilizator non-root cu sudo.
Pe unele distribuții, un fișier de configurare suplimentar poate suprascrie setările dvs. Verificați suprascrierile:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Dacă vreun fișier din acel director setează PasswordAuthentication yes, editați-l sau eliminați-l.
Validați sintaxa configurației înainte de repornire:
sshd -t
Un rezultat curat (fără erori) înseamnă că este sigur să reîncărcați. Aplicați modificările:
systemctl restart sshd
Avertisment critic: Nu închideți sesiunea SSH existentă înainte de a deschide un al doilea terminal și de a confirma că vă puteți autentifica în continuare cu cheia dvs. Repornirea sshd cu un fișier configurat greșit sau înainte ca cheia dvs. să funcționeze vă va bloca accesul. Majoritatea Panourilor de Control VPS oferă o consolă de urgență (acces KVM/VNC) pentru recuperare, dar este mult mai bine să evitați complet situația.
Pasul 8: Gestionați mai multe chei și servere cu ~/.ssh/config
Când gestionați mai multe servere — frecvent în mediile de staging/producție sau când administrați mai multe Servere Dedicate — fișierul de configurare al clientului SSH elimină necesitatea de a memora adrese IP, nume de utilizator și căi ale cheilor.
Creați sau editați ~/.ssh/config pe mașina dvs. locală:
nano ~/.ssh/config
Exemplu de configurare pentru mai multe gazde:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Setați permisiunile corecte pe fișierul de configurare:
chmod 600 ~/.ssh/config
Acum vă puteți conecta cu aliasuri simple:
ssh production-vps
ssh staging-vps
Directiva PubkeyAcceptedKeyTypes +ssh-rsa din intrarea pentru sistemul vechi este importantă: clienții OpenSSH mai noi (8.8+) dezactivează RSA-SHA1 în mod implicit. Fără această suprascriere, conexiunile la serverele mai vechi vor eșua cu o eroare criptică „no matching host key type”.
Depanare: De ce eșuează autentificarea prin cheie SSH
Chiar și cu o configurare corectă, mai mulți factori de mediu pot determina autentificarea prin cheie să revină în tăcere la solicitări de parolă:
Permisiuni greșite pe .ssh sau authorized_keys:
Rulați ls -la ~/.ssh/ pe server. Directorul trebuie să fie 700 și fișierul trebuie să fie 600. Orice permisiuni mai permisive determină OpenSSH să ignore fișierul.
Nepotrivire context SELinux sau AppArmor:
Pe sistemele RHEL/CentOS/AlmaLinux cu SELinux în modul enforcing, fișierul authorized_keys poate avea contextul de securitate greșit. Restaurați-l cu:
restorecon -Rv ~/.ssh
Directorul home greșit al utilizatorului:
Dacă directorul home al utilizatorului nu este accesibil la scriere doar de proprietar, SSH va refuza autentificarea prin cheie. Verificați cu:
ls -ld ~
Directorul home în sine nu trebuie să fie accesibil la scriere de grup sau de toți utilizatorii.
Directiva AuthorizedKeysFile care indică în altă parte:
Unele distribuții configurează AuthorizedKeysFile să utilizeze o cale non-standard (de ex., /etc/ssh/authorized_keys/%u). Verificați setarea activă:
sshd -T | grep authorizedkeysfile
Mai multe chei și conflicte ssh-agent:
Dacă ssh-agent rulează cu mai multe chei încărcate, serverul poate respinge conexiunea după prea multe încercări eșuate cu chei înainte de a o încerca pe cea corectă. Utilizați -i pentru a specifica explicit cheia, sau configurați IdentitiesOnly yes în ~/.ssh/config.
Firewall sau fail2ban care blochează IP-ul dvs.:
Dacă ați avut anterior mai multe încercări eșuate de autentificare, regulile fail2ban sau ufw/iptables pot fi blocat temporar IP-ul dvs. Verificați cu:
fail2ban-client status sshd
Rotirea și revocarea cheilor SSH
Rotirea cheilor este o practică de igienă a securității care este adesea neglijată. Pentru a revoca o cheie specifică, deschideți ~/.ssh/authorized_keys pe server și ștergeți linia corespunzătoare. Fiecare linie reprezintă o cheie — eliminarea ei revocă imediat accesul pentru deținătorul acelei chei private fără a afecta nicio altă cheie autorizată.
În scopuri de audit, utilizați comentarii distincte pe fiecare cheie (partea de după materialul cheii, de ex., alice@workstation-2024) pentru a putea identifica cărui utilizator sau dispozitiv îi aparține fiecare cheie. Când un angajat pleacă sau un dispozitiv este scos din uz, localizați cheia sa după comentariu și eliminați-o.
Pentru a vă roti propria cheie, generați o nouă pereche, adăugați noua cheie publică în authorized_keys, verificați că autentificarea funcționează cu noua cheie, apoi eliminați intrarea cheii vechi.
Listă de verificare practică

Generați chei Ed25519 în mod implicit; utilizați RSA 4096 doar pentru compatibilitate cu servere vechi
Protejați întotdeauna cheia privată cu o frază de acces puternică
Utilizați ssh-copy-id pentru implementarea rapidă și fără erori a cheilor când este posibil
Verificați că permisiunile directorului .ssh sunt 700 și că authorized_keys este 600

Întrebări frecvente

Pot adăuga mai multe chei publice SSH la același cont de utilizator VPS?

Da. Fiecare linie din ~/.ssh/authorized_keys este o cheie autorizată independentă. Adăugați câte o cheie pe linie. Aceasta este abordarea standard pentru acordarea accesului mai multor administratori sau de pe mai multe dispozitive — fiecare persoană sau dispozitiv deține o cheie privată unică, iar revocarea se face per linie.

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

Veți fi blocat din SSH. Recuperarea necesită utilizarea accesului la consola out-of-band a furnizorului dvs. de hosting (KVM/VNC), disponibil prin majoritatea panourilor de control de VPS Hosting. Din consolă, reactivați PasswordAuthentication yes în /etc/ssh/sshd_config, reporniți sshd și încărcați o nouă cheie. De aceea testarea autentificării prin cheie înainte de dezactivarea parolelor este obligatorie.

Este Ed25519 suportat pe toate serverele?

Ed25519 necesită OpenSSH 6.5 sau o versiune ulterioară (lansată în 2014). Orice distribuție Linux modernă — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — îl suportă nativ. Doar sistemele cu adevărat vechi necesită fallback la RSA.

Ar trebui să folosesc aceeași pereche de chei SSH pentru fiecare server pe care îl gestionez?

Este convenabil din punct de vedere operațional, dar creează un singur punct de compromitere. O practică mai bună este să utilizați o pereche de chei per rol sau mediu (de ex., o cheie pentru servere personale, una pentru infrastructura clienților). Aceasta limitează impactul dacă o cheie privată este vreodată expusă.

Încărcarea unei chei SSH afectează Certificatele SSL sau configurația serverului web?

Nu. Cheile SSH guvernează accesul terminal la sistemul de operare și sunt complet separate de certificatele TLS/SSL utilizate de serverele web (Apache, Nginx) pentru HTTPS. Acestea utilizează porturi diferite (22 față de 443), formate de chei diferite și lanțuri de încredere diferite. Modificarea unuia nu are niciun efect asupra celuilalt.