Unde sunt stocate cheile SSH în Linux — și cum să le gestionezi în siguranță

SSH (Secure Shell) este unul dintre cele mai critice instrumente din ecosistemul Linux. Administratorii de sisteme, dezvoltatorii și inginerii DevOps se bazează pe el zilnic pentru acces la servere la distanță, transferuri de fișiere securizate, automatizarea implementării și gestionarea infrastructurii. Deși majoritatea utilizatorilor interacționează cu SSH printr-o comandă simplă de terminal, adevărata coloană vertebrală a securității se află în perechile de chei SSH — credențiale criptografice care permit autentificarea fără parolă, fluxuri de lucru automatizate și control de acces întărit.

Indiferent dacă gestionezi o singură instanță de VPS Hosting sau orkestrezi accesul pe zeci de Servere Dedicate, înțelegerea exactă a locului în care sunt stocate cheile SSH — și cum să le gestionezi corect — nu este opțională. Este o cerință fundamentală de securitate.

Acest ghid acoperă totul: locații implicite de stocare a cheilor, chei de gazdă la nivel de sistem, configurații personalizate, cerințe de permisiuni și bune practici pentru gestionarea securizată a cheilor.

Ce sunt cheile SSH și de ce sunt importante?

Cheile SSH utilizează criptografie asimetrică pentru a autentifica utilizatorii și serverele. Fiecare pereche de chei constă din:

• Cheia privată — păstrată secret pe mașina client, niciodată partajată
• Cheia publică — plasată pe serverul distant pentru a verifica identitatea

Când te conectezi la un server, SSH utilizează o apăsătură criptografică pentru a verifica că dețin cheia privată corespunzătoare cheii publice de pe server — fără a transmite niciodată cheia privată în sine. Aceasta este fundamental mai sigură decât autentificarea bazată pe parolă.

Locația implicită de stocare a cheilor SSH (Chei utilizator)

Pentru orice utilizator standard Linux, cheile SSH sunt stocate într-un director ascuns din folderul home:

~/.ssh/

Aceasta se extinde la calea completă:

/home/username/.ssh/

Pentru utilizatorul root în special:

/root/.ssh/

Fișiere comune în interiorul ~/.ssh/

Când rulați ssh-keygen, cheile sunt scrise în acest director în mod implicit, dacă nu specificați explicit o cale diferită în timpul generării cheilor.

Locații SSH Key la nivel de sistem (Host Keys)

În afara cheilor utilizatorului, daemonul SSH (sshd) — componenta de pe partea serverului — menține propriul set de host keys. Acestea sunt stocate la nivel de sistem la:

/etc/ssh/

Host Key Files în /etc/ssh/

Aceste host keys au un scop diferit decât cheile utilizatorului. Când un client se conectează la un server pentru prima dată, serverul prezintă cheia sa publică host. Clientul stochează această amprentă în ~/.ssh/known_hosts. La conexiunile ulterioare, SSH verifică dacă amprenta se potrivește — protejând împotriva atacurilor man-in-the-middle.

> Important: Host keys sunt generate automat în timpul instalării serverului SSH. Nu ar trebui să trebuiască niciodată să le creezi manual, dar ar trebui să știi unde se află pentru scopuri de audit și backup.

Locații personalizate pentru chei SSH

Nu sunteți restricționat la directorul implicit ~/.ssh/. Cheile SSH pot fi generate și stocate oriunde pe sistemul de fișiere. Pentru a utiliza o cheie stocată într-o locație non-implicită, specificați-o explicit:

ssh -i /path/to/custom_key user@host

Utilizarea ~/.ssh/config pentru mai multe chei

Gestionarea mai multor servere, proiecte sau conturi de utilizator devine mult mai curată cu un fișier ~/.ssh/config corect configurat. Aceasta vă permite să definiți setări per-host, inclusiv care cheie să utilizați:

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

Cu această configurație, rularea ssh production-server utilizează automat cheia corectă fără niciun flag suplimentar.

Cum sunt utilizate cheile SSH: Client vs. Server

Conexiuni de ieșire (Client Side)

Când inițiezi o conexiune SSH, clientul SSH caută chei private în ~/.ssh/ în mod implicit. Aceste chei sunt utilizate pentru a te autentifica pe serverul remote.

Instrumentele care utilizează chei de client SSH includ:

• ssh — acces direct la shell-ul remote
• scp — copiere securizată de fișiere
• rsync — sincronizare de fișiere peste SSH
• git — atunci când se utilizează depozite remote bazate pe SSH

Conexiuni de intrare (Server Side)

Pe server, SSH verifică un fișier specific pentru a determina care utilizatori sunt autorizați să se conecteze:

~/.ssh/authorized_keys

Acest fișier conține o cheie publică pe linie. Fiecare intrare acordă deținătorului cheii private corespunzătoare permisiunea de a se conecta ca acel utilizator.

Exemplu practic: Dacă utilizatorul alice dorește să se conecteze prin SSH pe un server ca utilizator webadmin, cheia publică a lui Alice trebuie să fie prezentă în /home/webadmin/.ssh/authorized_keys — nu în propriul director home al lui Alice pe acel server.

Permisiuni de fișier — Critice pentru securitatea SSH

Aici este locul unde mulți administratori fac greșeli costisitoare. SSH este deliberat strict cu privire la permisiunile de fișier. Dacă permisiunile sunt prea deschise, SSH va refuza în tăcere să folosească cheile tale sau va respinge încercările de conectare în întregime.

Setări de permisiuni necesare

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

Tabel de referință pentru permisiuni

Pentru a corecta permisiunile într-o singură comandă:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

Generarea cheilor SSH în mod securizat

Preferați întotdeauna Ed25519 în locul RSA pentru cheile noi. Ed25519 oferă o securitate mai puternică cu dimensiuni de chei mai mici și performanță mai rapidă.

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

Pentru sistemele moștenite care necesită RSA, utilizați cel puțin 4096 biți:

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

Setați întotdeauna o parolă când vi se solicită. O parolă criptează cheia privată pe disc, deci chiar dacă un atacator obține acces la sistemul dvs. de fișiere, nu poate utiliza cheia fără parolă.

Gestionarea cheilor cu ssh-agent

Introducerea parolei de fiecare dată când utilizezi o cheie SSH devine impracticabilă. ssh-agent rezolvă aceasta prin memorarea cheilor decriptate în memorie pentru durata sesiunii tale.

Pornirea ssh-agent și adăugarea unei chei

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

Ti se va cere parola o singură dată. După aceea, operațiile SSH utilizează cheia memorată automat.

Comenzi utile ssh-agent

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

Copierea Cheilor Publice pe Servere Îndepărtate

Cel mai ușor mod de a instala cheia ta publică pe un server îndepărtat este cu ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Aceasta adaugă cheia ta publică la ~/.ssh/authorized_keys pe serverul îndepărtat și setează automat permisiunile corecte.

Dacă ssh-copy-id nu este disponibil, fă-o manual:

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

Auditarea și depanarea problemelor cu chei SSH

Jurnalizarea conexiunilor detaliate

Când autentificarea SSH eșuează, modul detaliat arată exact ce se întâmplă:

ssh -v user@host

Pentru mai multe detalii:

ssh -vvv user@host

Această ieșire arată care fișiere de identitate au fost încercate, dacă agentul a fost consultat și unde a eșuat autentificarea.

Verificați jurnalul SSH pe partea serverului

Pe serverul distant, evenimentele de autentificare SSH sunt înregistrate în:

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

Verificați fișierul authorized_keys

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

Bune practici de securitate a cheilor SSH

Gestionarea corectă a cheilor merge dincolo de cunoașterea locului unde sunt stocate fișierele. Urmați aceste practici pe fiecare sistem pe care îl gestionați:

1. Utilizați o cheie pe scop

Nu refolosiți aceeași cheie SSH în diferite medii, clienți sau proiecte. Utilizați chei separate pentru acces personal, automatizarea implementării și acces partajat în echipă.

2. Rotația cheilor în mod regulat

Tratați cheile SSH ca și parolele — rotați-le periodic, mai ales după plecarea membrilor echipei sau compromisuri suspectate.

3. Auditați fișierele authorized_keys

Revizuiți în mod regulat care chei publice sunt autorizate pe fiecare server. Eliminați orice chei care aparțin foștilor angajați, automatizării depreciate sau surselor nerecunoscute:

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. Dezactivați autentificarea prin parolă

Odată ce cheile SSH sunt configurate, dezactivați complet conectarea SSH bazată pe parolă în /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Reporniți sshd după modificări:

systemctl restart sshd

5. Restricționați utilizarea cheii root

Evitați utilizarea cheilor SSH root în mai multe medii. Utilizați în schimb conturi de utilizator cu sudo activat cu chei individuale.

6. Utilizați autentificarea bazată pe certificate pentru scalare

Pentru infrastructuri mari, luați în considerare certificatele SSH (printr-o autoritate de certificare SSH) în loc de gestionarea intrărilor individuale authorized_keys. Aceasta simplifică dramatic gestionarea accesului pe mai multe servere.

Chei SSH în mediile Cloud și Hosting

Atunci când implementați servere în mediile cloud sau de hosting gestionat, gestionarea cheilor SSH devine și mai critică. Majoritatea platformelor — inclusiv furnizorii de VPS Hosting — vă permit să injectați o cheie publică la momentul aprovizionării, oferindu-vă acces sigur imediat fără a fi nevoie să setați vreodată o parolă.

Pentru echipele care gestionează mai multe medii, luați în considerare asocierea strategiei dvs. de chei SSH cu o configurare structurată a Panourilor de Control VPS, care poate simplifica gestionarea utilizatorilor și controlul accesului în întreaga infrastructură.

Dacă rulați aplicații web sau servicii care necesită comunicare sigură dincolo de SSH, asocierea configurării serverului dvs. cu Certificate SSL configurate corespunzător asigură criptare end-to-end pentru tot traficul — nu doar pentru acces administrativ.

Pentru echipele care se bazează pe Email Hosting alături de infrastructura lor de server, gestionarea cheilor SSH se extinde la securizarea sistemelor care gestionează poșta dvs. — un alt motiv pentru care igienă consistentă a cheilor pe toate serverele este importantă.

Referință rapidă: Locații fișiere cheie SSH

Concluzie

Înțelegerea locului în care sunt stocate cheile SSH în Linux — și gestionarea lor cu disciplină — este una dintre cele mai importante abilități pentru oricine lucrează cu servere, fie că ești un dezvoltator solo sau parte a unei echipe mari de operații.

Pentru a rezuma principalele concluzii:

• Cheile utilizatorului se află în ~/.ssh/ și sunt utilizate pentru autentificarea pe partea client
• Cheile gazdei se află în /etc/ssh/ și identifică serverul pentru clienții care se conectează
• authorized_keys controlează accesul inbound — auditează-l regulat
• Permisiunile fișierelor sunt non-negociabile — permisiunile incorecte întrerup în tăcere SSH
• Ed25519 este tipul de cheie preferat pentru generarea de noi chei
• Folosește întotdeauna fraze de acces și ssh-agent pentru gestionarea zilnică a cheilor
• Rotează și auditează cheile ca parte a igienei tale regulate de securitate

Pe sistemele de producție — fie că rulezi Servere Dedicate sau infrastructură partajată — gestionarea greșită a cheilor SSH este unul dintre cei mai comuni vectori pentru acces neautorizat. Investiția de timp în a face asta corect aduce beneficii în securitate, fiabilitate și liniște sufletească.

Tratează cheile SSH cu aceeași grijă pe care ai da-o oricărei credențiale critice. Pentru că asta sunt exact.