Autentificarea cu parolă prin SSH este cea mai mare suprafață deschisă a unui server obișnuit. Împotriva ei sunt neputincioase și Fail2ban, și orice praguri: o mie de adrese cu câte o încercare pe oră nu ating niciodată limita, iar vor încerca exact atât timp cât ghicirea este în principiu posibilă. Cheile elimină însăși posibilitatea, iar aceasta este singura setare din toată lista de securizare care schimbă situația calitativ.

Un singur lucru sperie aici: să dezactivezi parola și să rămâi pe dinafară. Mai jos este ordinea în care asta este exclus.

Cheia

Se generează pe mașina proprie, nu pe server:

ssh-keygen -t ed25519 -C "laptop de lucru"

ed25519 în loc de RSA — mai scurtă, mai rapidă și fără întrebări despre lungime. RSA este necesar doar dacă vei accesa ceva foarte vechi; atunci -t rsa -b 4096.

O frază de acces pentru cheie merită pusă: fișierul cheii poate fi furat de pe laptop, iar fără frază funcționează imediat. Nu va trebui introdusă de fiecare dată — de asta se ocupă ssh-agent, iar pe macOS și pe majoritatea distribuțiilor Linux de desktop deja rulează.

Copierea pe server cu o singură comandă, cât timp parola încă funcționează:

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

Dacă ssh-copy-id nu este disponibil, conținutul fișierului .pub se adaugă ca linie în ~/.ssh/authorized_keys pe server. Drepturile contează: directorul .ssh — 700, fișierul — 600, proprietar utilizatorul însuși. Cu alte drepturi, sshd refuză în tăcere să citească fișierul, iar aceasta este cea mai frecventă cauză a situației „cheia nu funcționează”.

Verificarea care decide totul

Înainte de a dezactiva orice, deschide o a doua conexiune fără să o închizi pe prima:

ssh -o PasswordAuthentication=no user@203.0.113.25

Opțiunea interzice clientului să revină la parolă — adică, dacă autentificarea a reușit, a reușit tocmai cu cheia. Până când această comandă nu trece, nu poți trece la pasul următor. Iar prima conexiune nu o închidem până la capăt: prin ea se repară tot ce se poate strica.

Dezactivarea parolei și o capcană neevidentă

Setările le punem într-un fișier separat, ca actualizarea pachetului să nu le suprascrie. Dar numele fișierului contează:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Chestiunea este că OpenSSH folosește prima valoare întâlnită a unui parametru, nu ultima, așa cum se întâmplă aproape peste tot. Fișierele din sshd_config.d se citesc în ordine alfabetică, iar imaginile de cloud Ubuntu pun acolo 50-cloud-init.conf, în care adesea stă PasswordAuthentication yes. Fișierul tău cu numărul 90 nu va face atunci nimic: setarea pare scrisă, iar parola continuă să funcționeze. De aici numărul 10 — se citește mai devreme.

Ce a ieșit în cele din urmă nu trebuie ghicit:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Această comandă tipărește configurația în vigoare după toate includerile. Ei să-i dai crezare, nu conținutului fișierelor.

Apoi verificarea sintaxei și reîncărcarea lină a serviciului:

sudo sshd -t && sudo systemctl reload ssh

sshd -t este obligatoriu: o greșeală de tastare în configurație, la restart, lasă serviciul căzut, iar pe tine pe dinafară. În plus, reload nu rupe sesiunile deschise.

Ubuntu 24.04: portul nu se schimbă acolo

O capcană separată a versiunilor recente de Ubuntu: sshd pornește acolo printr-un socket systemd. Linia Port din sshd_config nu face nimic în acest mod — ascultă socketul, nu demonul. Dacă schimbi portul, pe el trebuie să îl modifici:

sudo systemctl edit ssh.socket

și să indici ListenStream= (valoarea goală anulează pe cea anterioară) cu portul nou. Simptomul după care se recunoaște: configurația schimbată, serviciul repornit, iar serverul răspunde în continuare pe 22.

Apropo de schimbarea portului: ca protecție nu funcționează — scanerele găsesc serviciul pe orice port în câteva minute. Singurul ei efect este liniștea din jurnale, pentru că ghicirea în masă merge doar pe 22. Este comod, dar nu confunda asta cu securitatea.

Cine are voie să se autentifice

O completare utilă este o listă explicită:

AllowUsers deploy admin

Tot ce nu este enumerat se respinge înainte de verificarea cheii. Asta acoperă totodată cazul în care vreun pachet creează un utilizator de sistem cu shell și director personal.

Intrarea de rezervă

O cheie pe un singur laptop este un singur punct de eșec. Discul moare, laptopul se pierde, iar serverul devine inaccesibil pentru totdeauna. Minimul rezonabil:

  • o a doua cheie de pe alt dispozitiv în authorized_keys;
  • o copie a cheii private într-un manager de parole sau pe un stick criptat;
  • acces verificat la consola furnizorului — VNC sau serial. Verificat înseamnă că te-ai autentificat acolo măcar o dată, nu că „există un buton undeva în panou”.

Uită-te totodată la ce se află deja în authorized_keys — și la utilizatorul tău, și la root. O cheie străină de acolo supraviețuiește oricărei schimbări de parolă și rămâne un acces funcțional.

După

Ghicirea parolelor nu dispare, doar că acum este inutilă: în jurnale vor rămâne mii de linii Failed password, dintre care niciuna nu se poate încheia cu succes. În schimb, acum merită să te uiți la autentificările reușite: de la ce adresă, cu ce utilizator, la ce oră. O autentificare reușită cu cheie de la o adresă necunoscută este un eveniment mult mai important decât un milion de încercări eșuate și mult mai greu de observat în fluxul general. Exact această imagine o arată pagina demonstrativă de mai jos.