Blocat din SSH? Cum recapeti accesul la VPS

Se intampla mereu in cel mai prost moment. Strangi putin firewall-ul, dai restart la SSH dupa o modificare “rapida” in config, sau formatezi laptopul vechi pe care era cheia, iar urmatoarea comanda ssh fie sta agatata, fie raspunde sec cu Permission denied. Serverul merge, site-ul probabil e inca online, dar usa prin care il administrezi s-a inchis. Vestea buna: cand esti blocat din SSH pe un VPS, situatia aproape niciodata nu e definitiva, pentru ca SSH nu e singura cale de intrare.

In ghidul asta facem recuperarea asa cum ar face-o un admin cu experienta. Intai citim ce ne spune de fapt clientul SSH. Apoi intram prin consola web out-of-band din zona de client si reparam cele cinci blocaje pe care le vedem cel mai des in tichetele de suport: o regula de firewall care blocheaza portul 22, un sshd_config stricat, un ban Fail2ban pe propriul IP, o cheie pierduta si login-ul cu parola dezactivat fara nicio cheie functionala. Toate comenzile sunt scrise pentru Debian 13 si Ubuntu 24.04, iar acolo unde cele doua se comporta diferit, spunem explicit.

De ce ai nevoie inainte sa incepi

• Acces la zona de client DreamServer (contul cu care ai comandat VPS-ul), ideal protejat cu 2FA.
• Adresa IP publica a VPS-ului si utilizatorul Linux cu care te loghezi de obicei. In exemple folosim 203.0.113.10 si alex; inlocuieste-le cu ale tale.
• Parola acelui utilizator, sau a lui root. Consola web e un simplu ecran de login si nu stie nimic de chei SSH. Daca n-ai setat niciodata o parola, Pasul 2 explica ce faci.
• Un terminal pe calculatorul tau: Terminal pe Linux sau macOS, ori PowerShell pe Windows 10/11, care vine cu clientul OpenSSH inclus.
• Cam 15-30 de minute si putina rabdare. Nu reinstala VPS-ul: iti sterge datele si aproape niciodata nu e necesar.

De ce merge consola web cand SSH nu merge

Hai sa definim piesele. SSH (Secure Shell) e protocolul criptat prin care obtii o linie de comanda pe un server aflat la distanta. Pe server, un program care ruleaza in fundal (un daemon) numit sshd asteapta conexiuni. El asculta pe un port, o usa numerotata pe adresa de retea a serverului; SSH foloseste implicit portul TCP 22.

Inainte sa ajunga la sshd, conexiunea ta trece prin alte straturi. Firewall-ul (ufw sau nftables pe Linux) e un filtru de pachete din kernel care decide ce porturi pot fi atinse. Fail2ban e un serviciu care urmareste log-urile de autentificare si baneaza temporar IP-urile care gresesc prea des. La final, sshd isi citeste configuratia si iti verifica cheia sau parola. Oricare dintre straturi te poate bloca, si toate stau pe drumul prin retea.

Consola web e out-of-band: stratul de virtualizare (hypervisor-ul) ii da VPS-ului un ecran si o tastatura virtuale, iar zona de client iti transmite acel ecran in browser, de obicei prin VNC, un protocol de ecran la distanta. E echivalentul unui monitor conectat direct la un server fizic. Tastele tale nu trec niciodata prin interfata de retea a VPS-ului, deci firewall-ul, Fail2ban si sshd pur si simplu nu intervin. Cat timp VPS-ul e pornit, ai un prompt de login text si poti repara totul din interior.

O nota pentru cei pe containere: pe un VPS KVM, consola arata ecranul virtual real, inclusiv boot loader-ul. Pe un VPS LXC (container neprivilegiat), consola se ataseaza la terminalul containerului direct de pe host. Ocoleste reteaua la fel de bine, dar nu exista boot loader sau kernel propriu, deci trucul cu GRUB din Pasul 2 nu se aplica acolo.

Procedura de recuperare pe scurt

Procesul are sapte pasi, dar nu ii vei rula pe toti. Pasii 1 si 2 se aplica mereu: citesti eroarea, apoi deschizi consola. Pasii 3-6 sunt remedieri alternative, cate una pentru fiecare cauza, si o aplici doar pe cea care se potriveste erorii tale (uneori doua, daca ai avut ghinionul sa aduni mai multe greseli). Pasul 7 inchide mereu cercul: testezi din afara si te asiguri ca nu a ramas nimic deschis.

Cat dureaza? Odata ce esti logat in consola si stii cauza, majoritatea remedierilor sunt o chestiune de minute. Cel mai lent caz e cand nu ai parola pentru niciun utilizator si ai nevoie de un boot de salvare, pentru ca implica un reboot si ceva tastat atent la boot loader. Graficul de mai jos arata timpi tipici de lucru efectiv din experienta noastra de suport; considera-i aproximativi.

Pasul 1: Citeste mesajul de eroare SSH

Textul erorii e cel mai util indiciu, si majoritatea il sar. Ruleaza comanda obisnuita cu -v (verbose), ca sa-ti explice clientul ce face:

ssh -v alex@203.0.113.10

Vei vedea o gramada de linii debug1:. Cele interesante sunt spre final. Daca apare connect to address 203.0.113.10 port 22: Connection timed out, pachetele n-au primit niciun raspuns. Daca apare Authentications that can continue: publickey, serverul e accesibil si iti spune ca accepta doar login cu cheie. Foloseste tabelul de mai jos ca sa legi mesajul de cauza:

Pe Windows poti testa si daca portul raspunde, fara SSH la mijloc:

Test-NetConnection 203.0.113.10 -Port 22

Ultima linie, TcpTestSucceeded : True sau False, iti spune daca pe portul 22 asculta ceva accesibil.

Un test ieftin dar foarte util: incearca dintr-o alta retea, de exemplu hotspot-ul de pe telefon. Daca SSH merge de pe hotspot dar nu de la birou, serverul e in regula si IP-ul biroului e banat de Fail2ban (Pasul 5) sau filtrat de o regula de firewall care permite doar anumite adrese (Pasul 3). Arunca si o privire in zona de client: daca VPS-ul apare oprit, porneste-l inainte de orice.

Pasul 2: Deschide consola web si logheaza-te

In zona de client, deschide VPS-ul si cauta butonul Console (sau VNC). Se deschide un tab nou cu un ecran negru si un prompt text de genul vps login:. Daca ecranul e complet negru, apasa o data Enter: probabil consola a stins doar afisajul.

Logheaza-te cu utilizatorul si parola. Cateva note practice despre tastatul intr-o consola web:

• Consola se comporta de obicei ca o tastatura US. Daca pe calculator ai layout romanesc sau german, caractere ca |, /, ~, y si z pot iesi altfel. Verifica si Caps Lock si Num Lock, pentru ca la parola nu vezi ce tastezi.
• Copy-paste de multe ori nu merge. Unele implementari de consola au un panou de clipboard sau “send text”; daca a ta are, foloseste-l pentru siruri lungi. Altfel tine comenzile scurte, motiv pentru care ghidul asta evita one-liner-ele lungi in pasii din consola.
• Aici te poti loga ca root daca root are parola. PermitRootLogin se aplica doar la SSH, nu si la consola locala.

Dupa login, ia-ti 30 de secunde sa te uiti in jur:

ip -br a
systemctl status ssh --no-pager
sudo ss -tlnp

ip -br a ar trebui sa arate IP-ul public pe o interfata marcata UP. Linia cu systemctl iti spune daca serviciul SSH ruleaza. Atat pe Debian cat si pe Ubuntu serviciul se numeste ssh (cu sshd ca alias). In output-ul ss, cauta o linie cu :22, de exemplu LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3)).

Aici Ubuntu 24.04 e diferit: foloseste socket activation, adica systemd tine el insusi deschis portul 22 (unitatea ssh.socket) si porneste ssh.service cand vine prima conexiune. Asa ca pe Ubuntu, ss poate arata systemd ca proprietar al portului 22, iar ssh.service poate spune inactive (dead) cat timp nu e nimeni conectat. E normal; verifica si systemctl status ssh.socket. Debian 13 nu foloseste socket activation implicit, deci asculta direct ssh.service.

Daca consola cere o parola pe care n-ai setat-o niciodata

Multe imagini de VPS te logheaza doar cu cheie SSH, deci se poate ca utilizatorul tau sa nu aiba deloc parola. Inainte de orice, verifica daca zona de client ofera o resetare a parolei de root sau o optiune de rescue pentru VPS-ul tau; daca da, aia e calea cea mai simpla. Pe un VPS KVM poti reseta parola si singur, din boot loader:

1. Da reboot la VPS din zona de client si deschide imediat consola.
2. Cand apare meniul GRUB, apasa e. Daca sistemul booteaza direct, da reboot din nou si apasa Esc (UEFI) sau tine apasat Shift (BIOS) imediat dupa reboot, ca sa apara meniul.
3. Gaseste linia care incepe cu linux, mergi la final si adauga un spatiu urmat de init=/bin/bash. Apasa Ctrl+X sau F10 ca sa bootezi.
4. Ajungi intr-un shell de root fara niciun login. Ruleaza:

mount -o remount,rw /
passwd alex
sync
exec /sbin/init

Prima comanda face discul inscriptibil, passwd seteaza o parola noua (alege una simpla temporar daca layout-ul tastaturii iti face figuri, si schimb-o apoi prin SSH), iar exec /sbin/init continua boot-ul normal. Trucul asta nu merge pe un VPS LXC, care nu are boot loader propriu: acolo folosesti optiunea de resetare din zona de client sau deschizi un tichet, iar noi setam parola din partea de host.

Pasul 3: Repara o regula de firewall care blocheaza portul 22

Clasicul: cineva ruleaza ufw default deny incoming si ufw enable si uita sa permita SSH inainte. Verifica ufw:

sudo ufw status numbered

Un output de “blocat” arata de obicei asa, cu porturile web deschise si nicio regula pentru SSH:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 80/tcp                     ALLOW IN    Anywhere
[ 2] 443/tcp                    ALLOW IN    Anywhere

Adauga regula. Daca ai mutat SSH pe alt port, permite acel numar in loc de 22:

sudo ufw allow 22/tcp

ufw verifica regulile in ordine si castiga prima potrivire. Daca vezi o regula DENY IN sau LIMIT IN pentru 22 deasupra unei reguli de allow, sterge-o dupa numar (de exemplu sudo ufw delete 3) sau pune regula de allow prima cu sudo ufw insert 1 allow 22/tcp. O regula LIMIT blocheaza un IP care deschide mai mult de 6 conexiuni in 30 de secunde, ceea ce poate musca scripturile de deploy. Daca te grabesti, sudo ufw disable opreste complet firewall-ul; doar nu uita sa repari regulile si sa rulezi din nou sudo ufw enable inainte sa pleci.

Pe Debian, ufw nu e instalat implicit, deci sudo ufw status poate raspunde command not found. In cazul asta uita-te direct la nftables:

sudo nft list ruleset

Semnalul de alarma e un chain de input cu policy drop; si nicio linie care accepta portul 22. Repara in configuratia persistenta, verifica sintaxa, apoi reincarca:

sudo nano /etc/nftables.conf
sudo nft -c -f /etc/nftables.conf
sudo systemctl restart nftables

In blocul chain input, adauga tcp dport 22 accept langa celelalte reguli de accept. nft -c doar verifica fisierul si nu afiseaza nimic daca e valid. Retine ca si ufw creeaza reguli nftables in spate; daca ai ufw instalat, repara prin ufw si nu edita de mana regulile generate de el. Ca ultima solutie, sudo nft flush ruleset sterge toate regulile pana la urmatorul reboot sau reload. Daca pe server ruleaza Docker, ruleaza dupa aceea sudo systemctl restart docker, pentru ca flush-ul sterge si regulile de care Docker are nevoie pentru containere.

Pasul 4: Repara un sshd_config stricat

Daca SSH raspunde cu Connection refused si systemctl status ssh arata failed, daemon-ul a refuzat sa porneasca, aproape mereu din cauza unei greseli de scriere in configuratie. sshd are un mod de test integrat care iti spune exact unde:

sudo sshd -t

Daca nu afiseaza nimic, configuratia e valida. Un fisier stricat produce ceva de genul:

/etc/ssh/sshd_config: line 42: Bad configuration option: PasswordAuthenticaton
/etc/ssh/sshd_config: terminating, 1 bad configuration options

Fii atent la numele fisierului: pe Debian si Ubuntu, fisierul principal include toate fisierele *.conf din /etc/ssh/sshd_config.d/, deci greseala poate fi intr-un drop-in. Deschide fisierul la linia raportata, repara si testeaza din nou:

sudo nano +42 /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart ssh

Daca sshd -t se plange de Missing privilege separation directory: /run/sshd, serviciul e oprit si directorul acela de runtime a disparut; creeaza-l cu sudo mkdir -p /run/sshd si testeaza din nou.

Si o configuratie valida te poate bloca. Afiseaza setarile efective, dupa ce toate include-urile au fost combinate:

sudo sshd -T | grep -Ei '^(port|listenaddress|passwordauthentication|pubkeyauthentication|permitrootlogin|allowusers|allowgroups) '

Cauta un port neasteptat (l-ai schimbat si ai uitat), un listenaddress care arata spre un IP vechi, sau o linie allowusers care nu-ti include utilizatorul. Ultima e perfida: AllowUsers cu un nume scris gresit respinge in liniste pe toata lumea.

Schimbarile de port se comporta diferit pe cele doua distributii. Pe Debian 13, sudo systemctl restart ssh e suficient. Pe Ubuntu 24.04, portul e citit de systemd cand construieste ssh.socket, deci dupa ce schimbi Port sau ListenAddress ai nevoie de:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Daca nu mai intelegi nimic dintr-un fisier modificat intens, ambele distributii pastreaza configuratia implicita din pachet. Salveaza-ti versiunea pentru mai tarziu si pune la loc varianta implicita:

sudo cp /etc/ssh/sshd_config /root/sshd_config.broken
sudo cp /usr/share/openssh/sshd_config /etc/ssh/sshd_config
sudo sshd -t

Apoi da restart la SSH cum am aratat mai sus si reaplica hardening-ul cu grija, cate o modificare pe rand.

Pasul 5: Scoate IP-ul tau din ban-ul Fail2ban

Fail2ban numara login-urile esuate pe fiecare IP si baneaza vinovatii pentru o vreme (implicit 10 minute, deseori mai mult pe setup-uri securizate). Cateva parole gresite, un password manager care incearca o intrare veche, sau un agent SSH care ofera cinci chei pot bana chiar biroul tau. In functie de actiunea de ban, vezi fie timeout, fie Connection refused. Verifica jail-ul de SSH:

sudo fail2ban-client status sshd

Output-ul arata Currently banned si o lista Banned IP list. Ca sa afli care e al tau, uita-te la cele mai recente ban-uri din log-ul Fail2ban, care sta in acelasi loc pe Debian si Ubuntu:

sudo grep -E 'Ban |Unban ' /var/log/fail2ban.log | tail -n 20

Liniile arata ca NOTICE [sshd] Ban 198.51.100.23. Compara cu IP-ul tau public (cauta “what is my IP” intr-un browser pe calculatorul tau, sau verifica in router). Apoi scoate-l din ban in toate jail-urile deodata:

sudo fail2ban-client unban 198.51.100.23

sudo fail2ban-client unban --all sterge toate ban-urile daca nu esti sigur. Verifica si sudo fail2ban-client status: daca exista un jail recidive, acesta baneaza recidivistii pentru mult mai mult timp, iar comanda unban de mai sus il curata si pe el.

Ca sa nu se repete, daca biroul are IP fix, adauga-l in ignoreip. Editeaza /etc/fail2ban/jail.local (creeaza-l daca nu exista; daca exista deja, adauga linia in sectiunea [DEFAULT] in loc sa inlocuiesti fisierul):

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 198.51.100.23

Aplica cu sudo fail2ban-client reload. Pune in whitelist doar adrese care sunt cu adevarat ale tale si stabile; pentru conexiunile de acasa cu IP care se schimba, e mai bine sa repari cauza (cheia sau parola gresita) decat sa faci whitelist.

Pasul 6: Recapata accesul cu cheie sau parola

Aici drumul prin retea functioneaza, dar autentificarea esueaza. Incepe prin a citi ce a logat sshd despre incercarea ta. Pe Debian 13 log-urile sunt doar in jurnalul systemd; Ubuntu 24.04 scrie in plus si /var/log/auth.log:

sudo journalctl -u ssh --since "30 min ago" --no-pager

Permission denied, desi cheia e buna

Linii tipice din log si ce inseamna:

• Authentication refused: bad ownership or modes for directory /home/alex/.ssh: permisiunile sunt prea largi, asa ca sshd iti ignora intentionat cheile.
• Invalid user admin: folosesti alt nume de utilizator decat cel de pe server.
• User alex not allowed because not listed in AllowUsers: intoarce-te la Pasul 4.

Repara proprietarul si permisiunile, cel mai des caz dupa ce ai copiat fisiere ca root:

sudo chown -R alex:alex /home/alex/.ssh
sudo chmod 700 /home/alex/.ssh
sudo chmod 600 /home/alex/.ssh/authorized_keys
sudo chmod go-w /home/alex

Verifica si ca authorized_keys contine efectiv cheia ta publica, pe un singur rand: cat /home/alex/.ssh/authorized_keys.

Cheie pierduta sau login cu parola oprit: o fereastra temporara cu parola

Daca cheia privata a disparut (laptop formatat, pierdut sau furat) si login-ul cu parola e dezactivat, sa tastezi o cheie publica de 100 de caractere intr-o consola web e reteta perfecta pentru greseli. Metoda curata e sa deschizi o fereastra scurta si controlata de login cu parola, sa trimiti o cheie noua prin SSH si apoi sa inchizi fereastra.

Mai intai asigura-te ca utilizatorul are o parola pe care o stii (sudo passwd alex). Apoi creeaza un fisier drop-in temporar:

sudo nano /etc/ssh/sshd_config.d/00-recovery.conf

Pune in el o singura linie:

PasswordAuthentication yes

De ce numele asta? Pentru majoritatea optiunilor, sshd pastreaza prima valoare pe care o citeste, iar Debian si Ubuntu includ fisierele drop-in la inceputul configuratiei principale, in ordine alfabetica. Un fisier care incepe cu 00- castiga deci in fata oricarui altuia, inclusiv a lui 50-cloud-init.conf de pe Ubuntu, care pe imaginile cloud seteaza des PasswordAuthentication no. Testeaza si aplica:

sudo sshd -t
sudo systemctl restart ssh
sudo sshd -T | grep -i '^passwordauthentication'

Ultima comanda trebuie sa afiseze passwordauthentication yes. Acum, pe calculatorul tau, genereaza o cheie noua si copiaz-o pe server:

ssh-keygen -t ed25519 -C "alex-laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub alex@203.0.113.10

ssh-keygen te intreaba unde sa salveze cheia (Enter accepta varianta implicita) si o parola de protectie (passphrase), pe care o recomandam. ssh-copy-id cere o data parola lui alex si adauga cheia publica pe server. PowerShell pe Windows nu are ssh-copy-id, asa ca foloseste in loc:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh alex@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Testeaza ca merge cheia, cu parolele dezactivate explicit din partea clientului:

ssh -o PasswordAuthentication=no alex@203.0.113.10

Daca primesti un shell, inchide fereastra: inapoi in consola (sau in noua sesiune SSH), sterge fisierul temporar si da restart la SSH:

sudo rm /etc/ssh/sshd_config.d/00-recovery.conf
sudo sshd -t
sudo systemctl restart ssh

Daca vechea cheie era pe un dispozitiv pierdut sau furat, deschide ~/.ssh/authorized_keys si sterge randul care se termina cu comentariul acelui dispozitiv. Fa la fel pe fiecare server pe care era folosita cheia.

Pasul 7: Testeaza din afara si securizeaza din nou

Tine tab-ul cu consola deschis pana cand ai dovedit ca SSH merge. Dintr-un terminal nou de pe calculatorul tau:

ssh -o PasswordAuthentication=no alex@203.0.113.10 'echo ok'

Ar trebui sa vezi ok. Apoi, pe server, confirma ca toate protectiile sunt la locul lor:

sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin) '
sudo ufw status
sudo fail2ban-client status sshd

Te astepti la passwordauthentication no, permitrootlogin no sau without-password (numele intern pentru prohibit-password), ufw active cu regula de SSH prezenta, si jail-ul pornit. Pe Debian cu nftables simplu, foloseste sudo nft list ruleset in loc de ufw.

Acum fa urmatoarea blocare mai putin probabila. Inainte de orice schimbare riscanta, programeaza un “undo” automat cu systemd-run, o metoda integrata de a rula o comanda mai tarziu:

sudo systemd-run --on-active=5m /usr/sbin/ufw disable

Afiseaza ceva de genul Running timer as unit: run-r1a2b3c4d.timer. Faci modificarea de firewall, testezi SSH dintr-un al doilea terminal, si daca totul e bine anulezi plasa de siguranta cu sudo systemctl stop run-r1a2b3c4d.timer (foloseste numele afisat). Daca te-ai blocat, firewall-ul se opreste singur dupa cinci minute. Aceeasi idee merge si pentru configuratia SSH: copiezi intai fisierul in /root/sshd_config.bak si programezi sudo systemd-run --on-active=5m /bin/sh -c 'cp /root/sshd_config.bak /etc/ssh/sshd_config && systemctl restart ssh'.

Alte obiceiuri care te salveaza: tine mereu o sesiune SSH deschisa cand dai restart la sshd, ruleaza sudo sshd -t inainte de fiecare restart, adauga regula de allow inainte de ufw enable, pastreaza o a doua cheie (pe alt dispozitiv sau o cheie hardware) in authorized_keys, si asigura-te ca utilizatorul tau cu sudo are parola, ca sa poti folosi oricand consola.

Greseli frecvente si depanare

Consola accepta utilizatorul, dar nu si parola. Aproape mereu e layout-ul tastaturii sau Caps Lock. Tasteaza intai parola in campul de utilizator ca sa vezi ce ajunge de fapt, apoi sterge-o.

Am setat PasswordAuthentication yes, dar parolele tot sunt refuzate. Alt fisier seteaza no mai devreme. Ruleaza sudo sshd -T | grep -i passwordauth ca sa vezi valoarea efectiva, si cauta blocuri Match la finalul sshd_config care o suprascriu pentru anumiti utilizatori.

Am schimbat portul pe Ubuntu 24.04 si SSH tot pe 22 asculta. Ai sarit peste sudo systemctl daemon-reload si sudo systemctl restart ssh.socket. Se intampla si invers: portul s-a schimbat, dar firewall-ul permite in continuare doar 22, deci nu uita sa permiti noul port in ufw inainte de restart.

Too many authentication failures. Agentul SSH ofera toate cheile pe care le are si serverul renunta dupa sase incercari. Indica clientului o singura cheie: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@203.0.113.10.

REMOTE HOST IDENTIFICATION HAS CHANGED. Normal dupa o reinstalare. Verifica amprenta noua in consola cu ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub si, doar daca se potriveste cu ce arata clientul, sterge intrarea veche cu ssh-keygen -R 203.0.113.10. Daca n-ai reinstalat nimic, opreste-te si investigheaza.

Pe server totul pare in regula, dar tot primesc timeout. Blocajul poate fi la tine: unele retele de birou sau de hotel blocheaza portul 22 spre exterior. Testul cu hotspot-ul din Pasul 1 lamureste situatia.

Serviciile nu repornesc fara un motiv clar. Verifica df -h. Un sistem de fisiere root plin 100% strica login-urile, logarea si restart-urile de servicii in moduri ciudate; elibereaza spatiu intai, apoi reincearca.

Note de securitate

• Consola web inseamna acces root pentru oricine controleaza contul tau din zona de client, din cauza trucului cu boot loader-ul din Pasul 2. Protejeaza contul cu o parola unica si 2FA.
• Nu lasa niciodata in urma starea de recuperare: sterge 00-recovery.conf, reporneste firewall-ul si asigura-te ca Fail2ban ruleaza. Un login cu parola “temporar” e genul de lucru care ramane ani de zile.
• Un dispozitiv pierdut sau furat inseamna o cheie compromisa. Scoate-o din authorized_keys peste tot si cauta login-uri pe care nu le recunosti cu sudo journalctl -u ssh | grep Accepted.
• Pe server ajunge doar fisierul .pub. Nu lipi niciodata o cheie privata intr-o consola, intr-un tichet sau pe chat.
• Tine ignoreip scurt si specific. Whitelist pe range-uri intregi de provider face Fail2ban inutil.
• Mutarea SSH pe un port nestandard reduce zgomotul din log-uri, dar nu e o masura de securitate. Cheile plus login-ul cu parola dezactivat sunt cele care te protejeaza cu adevarat.

Deci, esti vreodata blocat de-a binelea?

Rar. Cat timp VPS-ul booteaza si ajungi in zona de client, consola web iti da o cale de intrare pe care nicio regula de firewall, niciun ban si nicio greseala de scriere nu o pot bloca. Citesti intai eroarea, deschizi consola, repari singurul strat care e de fapt stricat, apoi testezi din afara si pui la loc toate protectiile. Data viitoare, un timer de “undo” de cinci minute si o a doua cheie fac tot exercitiul inutil.

Daca vrei un server la care consola, snapshot-urile si setarile sanatoase sunt acolo din prima zi, porneste cu un VPS gazduit in propriul nostru data center din Romania. Iar daca preferi sa nu-ti petreci seara intr-o fereastra VNC, echipa noastra de administrare servere iti poate recupera accesul, securiza SSH-ul si configura proceduri sigure de schimbare pentru tine.

Intrebari frecvente

Un reboot la VPS rezolva blocarea din SSH?

De obicei nu. Regulile de firewall, modificarile din sshd_config si cheile lipsa supravietuiesc unui reboot, iar Fail2ban isi pastreaza ban-urile intr-o mica baza de date si le reaplica la pornire. Un reboot ajuta doar daca serviciul SSH a cazut dintr-un motiv temporar, de exemplu lipsa de memorie.

Pot repara fara consola web?

Doar daca mai ai o alta cale de intrare: un al doilea utilizator cu o cheie functionala, un coleg cu acces sau un agent de management instalat anterior. Altfel, consola sau un tichet la suport sunt solutia.

Merge consola web pe un VPS LXC?

Da. Se ataseaza la terminalul containerului de pe host si ocoleste reteaua la fel. Ce nu poti face intr-un container LXC neprivilegiat e resetarea parolei din boot loader, pentru ca acel container nu are boot loader sau kernel propriu.

N-ar fi mai simplu sa reinstalez VPS-ul?

Doar ca ultima solutie, si doar dupa un backup. Reinstalarea sterge discul, pe cand fiecare blocare din ghidul asta se repara in cateva minute din consola, fara sa pierzi nimic.

E sigur sa activez temporar login-ul cu parola?

Pentru cateva minute, cu o parola puternica si Fail2ban pornit, riscul e mic. Pericolul e sa uiti sa-l opresti, motiv pentru care Pasul 6 foloseste un singur fisier drop-in pe care il stergi imediat ce noua cheie functioneaza.