De ce securitatea SSH este critică în 2026
SSH (Secure Shell) rămâne principala poartă de acces către serverele Linux. Asta nu e ceva nou — dar ce s-a schimbat dramatic este peisajul amenințărilor. În 2026, 79% din atacurile asupra sistemelor Linux din ultimul an nu au folosit malware. Au exploatat configurări greșite și credențiale furate. Atât de simplu.
Atacatorii folosesc acum inteligența artificială pentru a identifica versiunile de kernel, a scana porturi deschise și a construi payload-uri în câteva minute. Nu mai vorbim de scripturi rudimentare — e vorba de tooling avansat, disponibil oricui.
Cele mai recente vulnerabilități descoperite în OpenSSH (CVE-2025-26465, CVE-2025-26466 și CVE-2025-61984) arată clar că nici cel mai utilizat protocol de acces la distanță nu este imun. Hai să trecem prin fiecare aspect al securizării SSH — de la actualizarea versiunii OpenSSH, la configurarea avansată a sshd_config, chei Ed25519, FIDO2, Fail2Ban și chiar criptografie post-cuantică.
Vulnerabilități OpenSSH critice descoperite în 2025-2026
Înainte de a sări la configurare, merită să înțelegem amenințările recente. Trei CVE-uri majore au fost publicate în perioada 2025-2026 și, sincer, fiecare dintre ele e suficient de serios încât să justifice o actualizare imediată.
CVE-2025-26465 — Atac Man-in-the-Middle pe clientul SSH
Această vulnerabilitate permite un atac activ de tip machine-in-the-middle asupra clientului OpenSSH atunci când opțiunea VerifyHostKeyDNS este activată. Atacul funcționează indiferent dacă opțiunea e setată pe yes sau ask, nu necesită interacțiune din partea utilizatorului și nu depinde de existența unui record SSHFP în DNS.
Partea îngrijorătoare? Bug-ul a fost introdus în decembrie 2014 — înainte de lansarea OpenSSH 6.8p1. Deci a stat acolo, nedetectat, mai bine de un deceniu.
Versiuni afectate: OpenSSH 6.8p1 până la 9.9p1
Remediere:
- Actualizează la OpenSSH 9.9p2 sau mai nou
- Verifică și dezactivează
VerifyHostKeyDNSîn/etc/ssh/ssh_config
CVE-2025-26466 — Atac DoS pre-autentificare
Atât clientul, cât și serverul OpenSSH sunt vulnerabile la un atac de denial-of-service înainte de autentificare. Mecanismul e destul de elegant (din perspectiva atacatorului, bineînțeles): pentru fiecare pachet ping primit, serverul SSH alocă un pachet pong într-un buffer de memorie care nu se eliberează decât după finalizarea schimbului de chei.
Un client malițios poate trimite continuu astfel de pachete, provocând o creștere necontrolată a consumului de memorie. Practic, nici nu trebuie să se autentifice ca să pună serverul în genunchi.
Versiuni afectate: OpenSSH 9.5p1 până la 9.9p1
Remediere:
- Actualizează la OpenSSH 9.9p2
- Configurează parametrii
LoginGraceTime,MaxStartupsșiPerSourcePenaltiesînsshd_config
CVE-2025-61984 — Execuție de cod la distanță prin ProxyCommand
Aceasta e probabil cea mai periculoasă dintre cele trei. Permite injectarea de caractere de control în numele de utilizator atunci când sunt expandate prin ProxyCommand. Atacatorul poate injecta expresii shell executate la pornirea comenzii proxy. Afectează versiunile OpenSSH până la 10.0p1 inclusiv.
Remediere:
- Actualizează la OpenSSH 10.1 sau mai nou
- Auditează și elimină directivele
ProxyCommanddin configurațiile SSH unde nu sunt strict necesare
Verificarea versiunii curente de OpenSSH
ssh -V
# Exemplu output: OpenSSH_9.9p2, OpenSSL 3.2.1 30 Jan 2024
# Pe Debian/Ubuntu - actualizare:
sudo apt update && sudo apt upgrade openssh-server openssh-client
# Pe RHEL/Fedora/AlmaLinux:
sudo dnf update openssh-server openssh-clientsGenerarea cheilor SSH Ed25519
Ed25519 este standardul recomandat în 2026, și pe bună dreptate. Oferă securitate echivalentă cu RSA de ~3000 biți, dar cu o cheie de doar 256 biți. Generarea și verificarea sunt considerabil mai rapide, iar implementarea prezintă mai puține riscuri de atacuri side-channel comparativ cu RSA sau ECDSA.
Dacă încă folosești RSA pe servere, acum e un moment bun să faci tranziția.
Generarea perechii de chei
# Generează o cheie Ed25519 cu comentariu identificator
ssh-keygen -t ed25519 -C "admin@server-producție"
# Output:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/user/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# IMPORTANT: Folosește ÎNTOTDEAUNA o parolă (passphrase)!
# Fără passphrase, oricine obține acces la fișierul cheii private
# se poate autentifica pe orice server care o acceptă.Copierea cheii publice pe server
# Metoda automată (recomandată):
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilizator@adresa_server
# Metoda manuală:
cat ~/.ssh/id_ed25519.pub | ssh utilizator@adresa_server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Atenție la permisiuni: SSH va refuza silențios autentificarea bazată pe chei dacă permisiunile sunt incorecte. Directorul ~/.ssh trebuie să aibă permisiunea 700, iar fișierul authorized_keys trebuie să aibă 600. Am văzut de prea multe ori administratori care pierdeau ore întregi depanând conexiuni SSH, doar ca să descopere că lipsea un simplu chmod.
Utilizarea ssh-agent pentru gestionarea passphrase
# Pornește ssh-agent
eval "$(ssh-agent -s)"
# Adaugă cheia (va cere passphrase o singură dată)
ssh-add ~/.ssh/id_ed25519
# Verifică cheile încărcate
ssh-add -lConfigurarea avansată a sshd_config
Fișierul /etc/ssh/sshd_config este centrul de control al securității SSH. Acesta e locul unde se întâmplă magia (sau dezastrul, dacă nu ești atent). Mai jos e o configurație completă de hardening, cu explicații pentru fiecare directivă.
Configurație recomandată pentru producție
# /etc/ssh/sshd_config - Configurație securizată 2026
# --- Rețea și port ---
Port 2222 # Port alternativ (reduce scanările automate)
AddressFamily inet # Doar IPv4 (sau inet6 pentru IPv6, any pentru ambele)
ListenAddress 0.0.0.0 # Restricționează la interfața necesară
# --- Autentificare ---
PermitRootLogin no # NICIODATĂ login direct ca root
PubkeyAuthentication yes # Activează autentificarea cu cheie publică
PasswordAuthentication no # Dezactivează complet parolele
PermitEmptyPasswords no # Interzice parole goale
KbdInteractiveAuthentication no # Dezactivează challenge-response
MaxAuthTries 3 # Maxim 3 încercări de autentificare
AuthenticationMethods publickey # Doar cheie publică
# --- Tipuri de chei acceptate ---
PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-512,rsa-sha2-256
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
# --- Sesiuni și timeout ---
ClientAliveInterval 300 # Ping la client la fiecare 5 minute
ClientAliveCountMax 2 # Deconectare după 2 ping-uri fără răspuns
LoginGraceTime 30 # 30 secunde pentru autentificare
MaxSessions 3 # Maxim 3 sesiuni per conexiune
MaxStartups 3:50:10 # Rate limiting pentru conexiuni noi
# --- Funcționalități dezactivate ---
X11Forwarding no # Dezactivează X11 (vulnerabilități de escaladare)
AllowTcpForwarding no # Dezactivează port forwarding (dacă nu e necesar)
AllowAgentForwarding no # Dezactivează agent forwarding
PermitTunnel no # Dezactivează tunnel-uri
# --- Logging ---
LogLevel VERBOSE # Logging detaliat pentru audit
# --- Protecție DoS (CVE-2025-26466) ---
PerSourcePenalties crash:90,authfail:5,noauth:3
# --- Restricționare utilizatori ---
AllowUsers admin deploy # DOAR acești utilizatori pot accesa SSH
# AllowGroups ssh-users # Alternativ: permite pe bază de grupAplicarea configurației
# Verifică sintaxa ÎNAINTE de restart
sudo sshd -t
# Dacă nu sunt erori, reîncarcă serviciul
sudo systemctl reload sshd
# IMPORTANT: Nu închide sesiunea curentă până nu testezi
# o conexiune nouă într-un alt terminal!Avertisment critic: Testează întotdeauna configurația nouă deschizând o sesiune SSH separată ÎNAINTE de a închide sesiunea curentă. Am învățat asta pe pielea mea — o greșeală de configurare te poate bloca permanent din server. Și dacă e un server în cloud fără consolă serială... ei bine, o să ai o zi proastă.
Instalarea și configurarea Fail2Ban
Chiar și cu autentificarea bazată pe chei, atacurile automate brute-force nu se opresc. Consumă resurse și aglomerează jurnalele. Fail2Ban monitorizează jurnalele de autentificare și blochează temporar adresele IP care eșuează repetat — simplu, eficient și aproape obligatoriu pe orice server expus pe internet.
Instalare
# Debian/Ubuntu:
sudo apt install fail2ban
# RHEL/Fedora/AlmaLinux:
sudo dnf install fail2ban
# Activare la boot:
sudo systemctl enable fail2ban
sudo systemctl start fail2banConfigurare pentru SSH
Nu edita niciodată /etc/fail2ban/jail.conf direct — e suprascris la actualizări. Creează un fișier de override:
# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600 # Ban 1 oră
findtime = 600 # Fereastră de 10 minute
maxretry = 3 # Maxim 3 încercări eșuate
banaction = nftables # Folosește nftables (modern) în loc de iptables
[sshd]
enabled = true
port = 2222 # Portul tău SSH personalizat
filter = sshd
logpath = /var/log/auth.log # Debian/Ubuntu
# logpath = /var/log/secure # RHEL/Fedora
maxretry = 3
bantime = 7200 # Ban 2 ore pentru SSH
findtime = 900 # Fereastră de 15 minuteVerificare și monitorizare
# Verifică statusul jail-ului SSH:
sudo fail2ban-client status sshd
# Output exemplu:
# Status for the jail: sshd
# |- Filter
# | |- Currently failed: 2
# | |- Total failed: 147
# | `- File list: /var/log/auth.log
# `- Actions
# |- Currently banned: 3
# |- Total banned: 45
# `- Banned IP list: 203.0.113.42 198.51.100.7 192.0.2.15
# Deblochează manual o adresă IP:
sudo fail2ban-client set sshd unbanip 203.0.113.42Chei de securitate hardware FIDO2 pentru SSH
Începând cu OpenSSH 8.2, poți folosi chei hardware FIDO2 (YubiKey, SoloKey, Google Titan) ca chei SSH. Materialul cheii private nu părăsește niciodată dispozitivul hardware, ceea ce oferă cel mai înalt nivel de protecție împotriva furtului de credențiale.
Personal, consider că pentru orice server de producție cu date sensibile, o cheie FIDO2 ar trebui să fie obligatorie, nu opțională.
# Generează o cheie SSH legată de dispozitivul FIDO2
ssh-keygen -t ed25519-sk -C "admin-yubikey"
# Flag-ul -sk indică Security Key
# Va fi necesară atingerea fizică a cheii la fiecare autentificare
# Pentru a impune verificarea prezenței utilizatorului:
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin-yubikey"Chiar dacă mașina client este compromisă, atacatorul ar avea nevoie de acces fizic la dispozitivul hardware. E un nivel de securitate care merită investiția (cheile FIDO2 costă între 25-70 EUR).
Certificate SSH pentru automatizări CI/CD
Cheile SSH statice, pe termen lung, folosite pentru deploy-uri și pipeline-uri CI/CD reprezintă un risc serios. Le-ai generat acum doi ani, le-ai pus în secrets și ai uitat de ele — sună familiar? Certificatele SSH cu durată scurtă de viață sunt o alternativă mult mai sigură.
# 1. Creează o autoritate de certificare (CA) SSH
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "SSH CA Producție"
# 2. Adaugă CA în configurația serverului (sshd_config):
# TrustedUserCAKeys /etc/ssh/ca_key.pub
# 3. Semnează o cheie de utilizator cu durată de 1 oră:
ssh-keygen -s /etc/ssh/ca_key -I "deploy-pipeline" -n deploy -V +1h ~/.ssh/id_ed25519.pub
# 4. Verifică certificatul:
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pubAvantajul principal: nu mai trebuie să distribui chei publice pe fiecare server. Orice server care are încredere în CA va accepta automat certificatele semnate de aceasta. Iar expirarea automată elimină complet riscul cheilor uitate — ceea ce, să fim sinceri, e una dintre cele mai frecvente probleme de securitate în mediile de producție.
Criptografia post-cuantică în OpenSSH
Asta poate suna a science fiction, dar e deja realitate. Începând cu OpenSSH 9.x, schimbul de chei post-cuantic este activat implicit. Algoritmul hybrid sntrup761x25519-sha512 combină criptografia clasică (X25519) cu un algoritm rezistent la calculatoare cuantice (NTRU Prime).
# Verifică algoritmii de schimb de chei disponibili:
ssh -Q kex
# Asigură-te că sntrup761x25519-sha512 este listat
# Pe versiunile recente de OpenSSH, este activ implicit
# Poți forța utilizarea sa în ssh_config:
# KexAlgorithms sntrup761x25519-sha512,curve25519-sha256Computerele cuantice capabile să spargă criptografia actuală nu există încă. Dar conceptul de atac „colectează acum, decriptează mai târziu" face ca adoptarea criptografiei post-cuantice să fie o măsură prudentă. Dacă cineva interceptează traficul tău SSH azi și îl stochează, ar putea (teoretic) să-l decripteze peste 10-15 ani. Pentru comunicații sensibile pe termen lung, merită protecția suplimentară.
Monitorizarea și auditarea accesului SSH
O configurație bună fără monitorizare e ca o alarmă fără sirenă — inutilă. Jurnalele SSH trebuie analizate continuu pentru a detecta anomalii.
Verificarea jurnalelor SSH
# Jurnale în timp real:
sudo journalctl -u sshd -f
# Autentificări reușite din ultima zi:
sudo journalctl -u sshd --since "24 hours ago" | grep "Accepted"
# Tentative eșuate:
sudo journalctl -u sshd --since "24 hours ago" | grep "Failed"
# Listează toate sesiunile SSH active:
who
ss -tnp | grep sshAuditarea configurației cu sshd -T
# Afișează configurația efectivă completă (inclusiv valori implicite):
sudo sshd -T
# Verifică o setare specifică:
sudo sshd -T | grep -i passwordauthentication
# passwordauthentication no ← Corect!
# Scanează configurația cu Lynis (audit de securitate):
sudo lynis audit system --tests-from-group sshRedirecționarea jurnalelor către un sistem centralizat
Redirecționează jurnalele SSH către un sistem izolat — fie un server dedicat de loguri, fie o platformă SIEM. De ce? Dacă un atacator compromite serverul, primul lucru pe care îl face e să șteargă jurnalele. Dacă logurile sunt stocate în altă parte, ai în continuare dovezile de care ai nevoie.
Lista de verificare rapidă pentru securizarea SSH
Folosește această listă ca un checklist rapid pentru serverele tale:
- Versiune OpenSSH actualizată — minim 9.9p2, ideal 10.1+
- Autentificare exclusiv cu chei Ed25519 — parole dezactivate complet
- Login ca root dezactivat —
PermitRootLogin no - Port SSH schimbat — port alternativ + reguli firewall
- Fail2Ban activ — cu configurație pentru portul personalizat
- Timeout-uri configurate —
ClientAliveIntervalșiLoginGraceTime - Utilizatori restricționați —
AllowUserssauAllowGroups - Funcționalități inutile dezactivate — X11Forwarding, AgentForwarding
- Jurnale monitorizate — logging centralizat activ
- PerSourcePenalties configurat — protecție împotriva CVE-2025-26466
Întrebări frecvente (FAQ)
Este Fail2Ban necesar dacă folosesc doar autentificarea cu chei SSH?
Da, absolut. Chiar dacă atacatorii nu pot ghici o parolă, încercările constante de brute-force consumă resurse (CPU, memorie, bandwidth) și aglomerează jurnalele. Mai rău, pot masca atacuri mai sofisticate printre zgomotul de fond. Fail2Ban blochează aceste IP-uri automat, reducând zgomotul și eliberând resurse.
Cât de des ar trebui să rotez cheile SSH Ed25519?
Nu există o regulă universală, dar rotația anuală e o practică bună. Rotația imediată este necesară dacă: un dispozitiv cu cheia privată e pierdut sau furat, un angajat care avea acces părăsește organizația, sau suspectezi orice formă de compromitere. În condiții normale, cheile Ed25519 cu passphrase puternic pot funcționa în siguranță mai mulți ani.
Schimbarea portului SSH chiar ajută la securitate?
Sincer? Nu e o măsură de securitate propriu-zisă — e o măsură de reducere a zgomotului. Boții automatizați scanează implicit portul 22, iar mutarea pe un port alternativ elimină peste 90% din tentativele automate. Un atacator determinat va descoperi oricum portul prin scanare.
Dar asta nu înseamnă că e inutilă. Combinată cu autentificare bazată pe chei, Fail2Ban și reguli de firewall, face o diferență reală în volumul de atacuri pe care trebuie să le procesezi.
Cum verific dacă serverul meu este vulnerabil la CVE-2025-26465 sau CVE-2025-26466?
Rulează ssh -V pe server. Dacă versiunea e între 6.8p1 și 9.9p1, serverul e potențial vulnerabil la CVE-2025-26465. Dacă e între 9.5p1 și 9.9p1, e vulnerabil și la CVE-2025-26466. Singura remediere completă e actualizarea la OpenSSH 9.9p2 sau mai nou. Verifică și dacă VerifyHostKeyDNS e setat pe yes sau ask în configurația clientului — dacă da, dezactivează-l imediat.
Ce este criptografia post-cuantică în SSH și ar trebui să o activez?
Criptografia post-cuantică protejează comunicațiile împotriva unui scenariu viitor în care computerele cuantice ar putea sparge algoritmii criptografici actuali. Vestea bună: dacă rulezi OpenSSH 9.x sau mai nou, algoritmul hybrid sntrup761x25519-sha512 e deja activ implicit. Nu trebuie să faci nimic special — doar asigură-te că nu ai restricționat manual algoritmii de schimb de chei într-o configurație mai veche.