SSH este ușa principală a serverului. Într-o firmă de outsourcing cu zece dezvoltatori, un contabil extern și un administrator plecat anul trecut, întrebarea nu este dacă ușa e încuiată, ci cine mai are cheie și dacă știi asta.
Două setări fac diferența: PasswordAuthentication no și PermitRootLogin no. Prima elimină complet atacurile prin ghicirea parolei, indiferent cât de insistenți sunt boții. A doua obligă fiecare persoană să intre pe contul propriu și să obțină drepturi prin sudo, deci jurnalul arată cine a făcut ce. Cheia ed25519 este scurtă, rapidă și fără parametri de configurat greșit. Fraza de acces protejează laptopul furat; agentul SSH o cere o dată pe sesiune. Tot restul, inclusiv portul, este zgomot redus, nu securitate.
Mutarea SSH de pe portul 22 reduce mult numărul de încercări din jurnal, fiindcă boții simpli scanează doar porturile uzuale. Un atacator interesat de serverul tău scanează toate porturile în câteva secunde. Deci portul schimbat ține jurnalul curat, nu ține intrușii afară. fail2ban este util fiindcă limitează cererile și reduce încărcarea, dar fără parole activate nu mai are ce proteja. Ordinea corectă: chei, apoi root interzis, apoi restul.
Într-o echipă, riscul real nu sunt boții, ci cheile uitate. Un fost coleg cu cheia încă în authorized_keys pe serverul de producție are acces oricând. Regula: o cheie pe persoană și pe dispozitiv, comentariu cu numele și data, și un inventar al cheilor pe fiecare server. AllowUsers sau AllowGroups restrânge lista de conturi care pot măcar încerca să se conecteze. Pentru conturile de deploy automatizat, limitează cheia la o comandă fixă cu opțiunea command= și interzice forwarding-ul.
| Setare | Valoare recomandată | Ce oprește |
|---|---|---|
| PasswordAuthentication | no | ghicirea parolelor, indiferent de volum |
| PermitRootLogin | no | acțiuni anonime ca root, țintă fixă pentru boți |
| AllowUsers / AllowGroups | lista explicită de conturi | încercări pe conturi de sistem |
| MaxAuthTries | 3 | sesiuni lungi de încercări repetate |
| X11Forwarding | no | suprafață inutilă pe un server |
ssh-keygen -t ed25519 -a 64 -C "ion.popescu@exemplu.md 2026-09"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@exemplu.mdPasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AllowGroups ssh-users
MaxAuthTries 3
X11Forwarding no
# apoi: sshd -t && systemctl reload sshapt install fail2ban
printf '[sshd]\nenabled = true\nmaxretry = 4\nbantime = 1h\n' > /etc/fail2ban/jail.d/sshd.local
systemctl restart fail2ban && fail2ban-client status sshdToți foloseau contul root cu o singură cheie partajată prin chat. După trecerea pe conturi individuale cu sudo, un audit cerut de clientul olandez a putut arăta exact cine s-a conectat și când. Cheia comună a fost revocată în aceeași zi.
Contabilul avea acces SSH cu parolă pentru a descărca exporturi pentru SFS. Serverul primea zeci de mii de încercări pe zi. Acum are un cont limitat la o comandă de export, cu cheie proprie, iar parolele sunt dezactivate.
Nu activa parolele pe server. Generează tu perechea de chei, trimite-i partea privată pe un canal sigur și fraza de acces pe altul, sau folosește un panou web pentru ce are nevoie. O excepție pentru un singur cont deschide ușa pentru toți.
Pentru serverele cu date sensibile, da: un al doilea factor protejează situația în care laptopul cu cheia și fraza salvată în agent este compromis. Pentru conturile de deploy automatizat nu are sens; acolo limitezi cheia la o comandă și la o adresă sursă.
Acest ghid adună într-un singur loc măsurile care contează pentru un server de producție al unei firme din Moldova: de la cheia SSH până la copia de backup pe care nimeni nu o poate șterge. Fiecare capitol trimite la o pagină de întrebare cu pași, comenzi și exemple. Este scris pentru echipe care livrează clienților din UE, raportează la instituții locale sau vând online și nu își permit o zi de indisponibilitate.