Salt la conținut

Setări cookie-uri

Alegeți pentru fiecare tip ce cookie-uri permiteți. Puteți modifica oricând alegerea prin Setări cookie-uri, în partea de jos a fiecărei pagini. Declarație de confidențialitate

Necesare

Mereu active

Necesare pentru autentificare, pentru păstrarea coșului și pentru a vă reține alegerile. Acestea sunt mereu active.

Ce cookie-uri?
  • weboke_sessie, weboke_klant, weboke_remember: sesiunea și menținerea autentificării
  • weboke_basket: coșul de cumpărături
  • wkBtwIncl: afișarea prețurilor cu sau fără TVA
  • wok_cookies: alegerea privind cookie-urile, 12 luni

Măsoară ce reclamă duce la o vizită sau o comandă, ca să nu plătim pentru reclame care nu aduc nimic.

Ce cookie-uri?
  • Google Ads prin Google Tag Manager (_gcl_au, _gcl_aw), până la 90 de zile
  • OpenAI Ads, reclame în ChatGPT
  • wok_aff: prin ce partener ați ajuns la noi (program de afiliere), 60 de zile

4,6

Țară și limbă

Fiecare țară are propriul site, cu prețurile și TVA-ul pentru țara respectivă.

Vedeți

Crearea și folosirea cheilor SSH

Modulul 2: SSH și chei · Timp de citire: 10 minute

Obiectivul lecției: După această lecție veți putea crea o pereche de chei, pune cheia publică pe server, vă veți putea autentifica fără parolă și veți ști să vă păstrați cheia privată astfel încât un laptop pierdut să nu devină o catastrofă.

Noțiuni cheie: pereche de chei, cheie publică, cheie privată, ed25519, RSA, passphrase, ssh-agent, ssh-copy-id, authorized_keys, permisiunile 700 și 600, câte o cheie pentru fiecare dispozitiv, cheie FIDO2

De ce cheile sunt mai bune decât parolele

În lecția 1.3 v-ați autentificat cu o parolă. Funcționează, dar un server conectat la internet primește încă din primul minut vizite de la programe care încearcă să ghicească parole. Uitați-vă în jurnalul unui server proaspăt instalat:

root@web1:~# journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"
214

Sute de încercări pe oră sunt ceva normal. O parolă puternică le oprește, dar ați creat un punct slab de care nu aveți nevoie. Cu o cheie SSH, ghicitul nu are sens: nu există nimic de ghicit care să apară într-o listă de cuvinte.

O cheie este formată din două părți care merg împreună, o pereche de chei:

  • Cheia privată rămâne pe propriul dumneavoastră calculator. Cine are acest fișier (și cunoaște passphrase-ul) se poate autentifica. Nu o împărtășiți cu nimeni, nici cu furnizorul dumneavoastră, nici cu un serviciu de asistență.
  • Cheia publică o dați serverului. Oricine o poate vedea: cu ea nu vă puteți autentifica, ci doar verifica.

La autentificare, serverul nu trimite nicio parolă prin rețea. Calculatorul dumneavoastră dovedește printr-o semnătură că deține cheia privată, iar serverul verifică semnătura cu ajutorul cheii publice. Chiar dacă cineva urmărește traficul din rețea, nu vede nimic ce ar putea refolosi ulterior.

Crearea unei chei

Cheia o creați pe propriul dumneavoastră calculator, nu pe server. Pe Windows 10 și 11, macOS și Linux, ssh-keygen este deja inclus. Deschideți PowerShell sau Terminal:

anna@laptop:~$ ssh-keygen -t ed25519 -C "anna@laptop 2026"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/anna/.ssh/id_ed25519):
Enter passphrase for "/home/anna/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anna/.ssh/id_ed25519
Your public key has been saved in /home/anna/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026

Ce se întâmplă aici?

  • -t ed25519 alege tipul. Ed25519 este scurt, rapid și sigur, iar începând cu OpenSSH 9.5 este și tipul implicit dacă nu specificați nimic. Dacă trebuie să lucrați cu un sistem vechi care nu cunoaște ed25519, folosiți RSA cu cel puțin 3072 de biți: ssh-keygen -t rsa -b 4096. Tipurile mai vechi, precum DSA, au fost eliminate din OpenSSH; nu le folosiți.
  • -C este doar un comentariu. Scrieți acolo ceva după care să recunoașteți mai târziu de pe ce dispozitiv provine cheia. Acest lucru ajută enorm când trebuie să revocați o cheie.
  • Passphrase-ul criptează cheia privată pe disc. Dacă vă este furat laptopul, hoțul are doar un fișier criptat. Fără passphrase, are acces direct la toate serverele dumneavoastră.

Acum aveți două fișiere:

FișierCe esteSe poate împărtăși?
~/.ssh/id_ed25519Cheia privatăNiciodată
~/.ssh/id_ed25519.pubCheia publică, un singur rând de textDa, către server

Pe Windows, acestea se află în C:\Users\anna\.ssh\. Cheia publică este un singur rând care începe cu ssh-ed25519:

anna@laptop:~$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHk2... anna@laptop 2026

Punerea cheii publice pe server

Serverul caută cheile publice în fișierul ~/.ssh/authorized_keys al utilizatorului cu care vă autentificați. Fiecare rând reprezintă o cheie. Există trei moduri de a vă pune cheia acolo:

1. La instalare. Majoritatea furnizorilor oferă, la crearea sau reinstalarea unui VPS, un câmp pentru cheia dumneavoastră publică. La WebOké, acest câmp se numește „Cheie SSH” în ecranul VPS; la alți furnizori funcționează similar. Aceasta este cea mai bună metodă: astfel nu este nevoie să fie activată vreodată autentificarea cu parolă.

2. Cu ssh-copy-id (macOS și Linux), cât timp autentificarea cu parolă încă funcționează:

anna@laptop:~$ ssh-copy-id anna@192.0.2.10
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed
anna@192.0.2.10's password:
Number of key(s) added: 1

3. Manual, de exemplu de pe Windows sau prin consola furnizorului dumneavoastră. Lipiți rândul din fișierul .pub în authorized_keys și setați corect permisiunile:

anna@web1:~$ mkdir -p ~/.ssh
anna@web1:~$ nano ~/.ssh/authorized_keys
anna@web1:~$ chmod 700 ~/.ssh
anna@web1:~$ chmod 600 ~/.ssh/authorized_keys

Aceste permisiuni nu sunt un detaliu. Serverul SSH le verifică (setarea StrictModes este activată implicit): dacă alții pot scrie în folderul dumneavoastră .ssh sau în directorul dumneavoastră personal, serverul vă ignoră cheile. Veți vedea pur și simplu din nou o solicitare de parolă, fără un mesaj de eroare clar. Cum se citesc permisiunile veți învăța în lecția 3.1.

Testați apoi într-o fereastră nouă:

anna@laptop:~$ ssh anna@192.0.2.10
Enter passphrase for key '/home/anna/.ssh/id_ed25519':
anna@web1:~$

Solicitarea vine acum de la propriul dumneavoastră calculator (passphrase-ul cheii), nu de la server.

ssh-agent: deblocare o singură dată

Să introduceți passphrase-ul de fiecare dată este incomod. ssh-agent păstrează cheia deblocată în memorie cât timp sunteți autentificat pe calculatorul dumneavoastră:

anna@laptop:~$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/anna/.ssh/id_ed25519:
Identity added: /home/anna/.ssh/id_ed25519 (anna@laptop 2026)
anna@laptop:~$ ssh-add -l
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)

Pe macOS, agentul se leagă de Keychain (Portchei); pe Windows este serviciul „OpenSSH Authentication Agent” (îl activați o singură dată în Servicii). Astfel aveți comoditatea de a nu introduce parole și totuși o cheie criptată pe disc.

Atenție la agent forwarding (ssh -A): prin aceasta, serverul pe care vă autentificați poate folosi agentul dumneavoastră. Cine este root pe acel server poate continua apoi cu cheia dumneavoastră. Folosiți această opțiune doar pe servere în care aveți încredere deplină sau folosiți ProxyJump (lecția 2.3).

Câte o cheie pentru fiecare dispozitiv și să știți unde se află fiecare

O greșeală frecventă: copierea aceleiași chei private pe laptop, PC și telefon. Dacă pierdeți un dispozitiv, trebuie să înlocuiți cheia peste tot și să reconfigurați toate dispozitivele. Mai bine:

  • creați pe fiecare dispozitiv o cheie proprie, cu un comentariu clar (-C "anna@telefoon");
  • puneți toate cheile publice în authorized_keys, câte una pe rând;
  • dacă pierdeți un dispozitiv, eliminați doar acel rând.

Verificați regulat ce chei au acces:

anna@web1:~$ ssh-keygen -lf ~/.ssh/authorized_keys
256 SHA256:q3J8vX0bT2kPz9mWc1nR4sLh7uYdE5aF6gBiC0oN2xQ anna@laptop 2026 (ED25519)
256 SHA256:Zt5oP1yW8eQ3rK6sV0bN9mD2xA4cH7jL1uI5fG8tE3w anna@telefoon (ED25519)

Dacă apare o cheie pe care nu o recunoașteți, acesta este un semnal de alarmă (lecția 10.3). Atacatorii își pun adesea propria cheie în authorized_keys pentru a reveni mai târziu.

O cheie hardware (FIDO2, precum un YubiKey) este de asemenea o opțiune. Cu ssh-keygen -t ed25519-sk, partea secretă se află pe cheia propriu-zisă și trebuie să o atingeți la fiecare utilizare. Un fișier furat nu mai valorează nimic. Este un pas frumos înainte, dar nu este necesar pentru început.

V-ați pierdut cheia privată?

Dacă vă pierdeți singura cheie privată și autentificarea cu parolă este dezactivată, nu mai puteți intra prin SSH. De aceea:

  • puneți întotdeauna cel puțin două chei pe server (de exemplu, laptop și PC);
  • aflați cum funcționează consola furnizorului dumneavoastră (lecția 1.2). Acolo vă autentificați ca și cum ați conecta o tastatură la server, iar acest lucru funcționează și fără SSH. La WebOké se numește Consolă în ecranul VPS; alți furnizori o numesc consolă VNC, consolă web sau consolă de urgență.

Pe AlmaLinux și Rocky Linux

Totul din această lecție funcționează la fel. O capcană în plus: cu SELinux activat, ~/.ssh trebuie să aibă eticheta de securitate corectă. Dacă ați creat sau copiat folderul manual și cheia vă este ignorată, restorecon -Rv ~/.ssh rezolvă problema.

Rezumat

  • O pereche de chei constă dintr-o cheie privată (rămâne la dumneavoastră) și o cheie publică (merge pe server, în ~/.ssh/authorized_keys).
  • Creați cheile cu ssh-keygen -t ed25519 pe propriul calculator, cu un passphrase; folosiți ssh-agent pentru comoditate.
  • Permisiunile contează: ~/.ssh pe 700 și authorized_keys pe 600, altfel serverul vă ignoră cheia.
  • Câte o cheie pentru fiecare dispozitiv, cu un comentariu clar, ca să puteți revoca doar una.
  • Aveți o a doua cheie și cunoașteți consola furnizorului ca intrare de urgență.

Test (quiz)

1. Ce fișier puteți da furnizorului dumneavoastră sau unui coleg pentru a primi acces la un server?



2. Ați pus cheia în authorized_keys, dar serverul tot cere o parolă. Care este o cauză frecventă?



3. De ce puneți un passphrase pe cheia privată?



4. Laptopul v-a fost furat. Pe server există trei chei: laptop, PC și telefon, fiecare cu propriul comentariu. Ce faceți?



5. Care este riscul folosirii ssh -A (agent forwarding) către un server în care nu aveți încredere?



Exercițiu

Exercițiul O2.1: Creați și folosiți o cheie. Creați pe propriul calculator o cheie ed25519 cu un passphrase și un comentariu clar, puneți-o pe server (prin câmpul furnizorului, cu ssh-copy-id sau manual), verificați permisiunile și autentificați-vă cu cheia într-o fereastră nouă. Apoi completați amprenta cheii dumneavoastră (din ssh-keygen -lf ~/.ssh/id_ed25519.pub) și răspundeți la întrebările despre locul în care se află cheia privată și ce faceți dacă o pierdeți. Programul verifică doar dacă amprenta are formatul corect; restul îl faceți singur.

Exercițiul O2.1: Creați și folosiți o cheie

Acest exercițiu îl faceți singur; nimeni nu îl verifică. Bifați ce ați făcut și marcați exercițiul ca finalizat.




Bifele și notițele dumneavoastră rămân doar în acest browser; nu le trimitem nicăieri. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că ați finalizat exercițiul.

Lecturi suplimentare

Pașii din aceste articole se aplică ecranului VPS și panourilor WebOké; la alți furnizori funcționează similar.

Un moment…

Configurați domeniile

Stabiliți pentru fiecare domeniu nameserverele, legătura cu hostingul și cine devine titularul.

Se încarcă domeniile…