Configurare initiala server Ubuntu si Debian: sudo si chei SSH

Un VPS proaspat livrat seamana cu un apartament nou la care cheile au ramas lipite cu banda adeziva pe usa. La cateva minute dupa ce serverul primeste o adresa IP publica, boti automati incep sa bata la portul 22 si sa incerce combinatii de tipul “root / 123456” sau “admin / admin”, de mii de ori pe zi. Cei mai multi nu reusesc, dar “cei mai multi” nu e o strategie de securitate. Vestea buna e ca sa inchizi usa cum trebuie dureaza cam o jumatate de ora si o faci o singura data.

In ghidul asta de configurare initiala pentru Ubuntu si Debian facem exact ce facem si noi pe fiecare masina noua: cream un utilizator obisnuit cu drepturi sudo, ne logam cu o cheie SSH in loc de parola (din Windows, macOS sau Linux), apoi oprim login-ul cu root si cu parola intr-un fel care nu te poate lasa pe dinafara. Totul functioneaza la fel pe Debian 13 si pe Ubuntu 24.04, iar putinele locuri unde difera le semnalam pe parcurs.

Ce facem, si de ce

Inainte de comenzi, cateva notiuni care apar peste tot in articol:

• root e contul de administrator atotputernic pe Linux. Poate citi, modifica sau sterge orice, asa ca o singura greseala de tastare sau o parola de root furata inseamna ca tot serverul e compromis.
• sudo (“superuser do”) ii permite unui utilizator obisnuit sa ruleze cate o comanda cu puteri de root, dupa ce isi tasteaza propria parola. Lucrezi zi de zi ca utilizator normal, ridici privilegiile doar cand chiar e nevoie, iar fiecare comanda sudo e inregistrata in log.
• SSH (Secure Shell) e protocolul criptat prin care obtii un terminal pe server. Programul care raspunde pe partea de server se numeste sshd (daemon-ul SSH) si asculta implicit pe portul 22. Un port e pur si simplu o “usa” numerotata a adresei IP; fiecare serviciu de retea asculta in spatele propriului numar.
• O cheie SSH e o pereche de fisiere: o cheie privata care sta pe calculatorul tau si nu pleaca niciodata de acolo, si o cheie publica pe care o copiezi pe server. Serverul poate verifica faptul ca detii cheia privata fara ca ea sa treaca vreodata prin retea.
• Un firewall e un filtru care decide ce porturi accepta conexiuni din internet.

Asta e imaginea pe care o construim: o singura cale legitima de intrare, prin cheie si un utilizator personal, iar restul respins.

Planul are opt pasi scurti. Ordinea conteaza: mai intai construim noua intrare (utilizator plus cheie), o testam, si abia apoi inchidem vechea intrare (root plus parole). In ordinea asta sta tot secretul ca sa nu ramai niciodata blocat afara.

De ce ai nevoie

• Un VPS DreamServer proaspat (sau orice server KVM ori LXC) cu Debian 13 sau Ubuntu 24.04, plus adresa IP publica si parola de root sau cheia SSH de root primite la livrare.
• Un calculator cu terminal: Terminal pe macOS si Linux, PowerShell sau Windows Terminal pe Windows 10 si 11. Ambele versiuni de Windows au deja clientul OpenSSH inclus, deci nu ai nevoie de PuTTY.
• Aproximativ 30 de minute si acces la consola web a VPS-ului din contul de client, pentru orice eventualitate. Foarte probabil nu o vei folosi, dar e plasa ta de siguranta daca ceva nu merge.

In tot ghidul folosim 203.0.113.10 ca IP al serverului si alex ca nume de utilizator. Inlocuieste-le cu valorile tale.

Pasul 1: Te loghezi ca root si actualizezi sistemul

Deschide un terminal pe calculatorul tau si conecteaza-te:

ssh root@203.0.113.10

La prima conexiune, SSH afiseaza un mesaj de genul:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:x9Qm...k2Lw.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

E serverul care se prezinta. Calculatorul tau nu l-a mai vazut niciodata, asa ca iti cere confirmarea. Scrie yes; amprenta (fingerprint-ul) se salveaza in ~/.ssh/known_hosts, iar de acum incolo SSH te avertizeaza clar daca identitatea serverului se schimba vreodata. Apoi introdu parola de root.

Cand vezi un prompt care se termina cu # (semnul ca esti root), adu toate pachetele la zi:

apt update && apt upgrade -y

apt update reimprospateaza lista de pachete disponibile, iar apt upgrade -y instaleaza versiunile noi fara sa mai ceara confirmare. Pe o imagine proaspata dureaza un minut sau doua. Daca s-a instalat un kernel nou, va exista fisierul /var/run/reboot-required; in cazul asta ruleaza reboot, asteapta vreo 30 de secunde si logheaza-te din nou.

Pasul 2: Creezi un utilizator obisnuit cu drepturi sudo

Asta e miezul oricarei configurari initiale pe Ubuntu sau Debian: nu mai lucrezi ca root. Pe o imagine Debian minimala, sudo s-ar putea sa nu fie instalat (Ubuntu il are mereu), asa ca il instalam intai. Daca exista deja, apt iti spune pur si simplu asta:

apt install -y sudo

Acum creezi utilizatorul:

adduser alex

adduser e unealta prietenoasa, interactiva: creeaza directorul personal /home/alex, copiaza fisierele implicite de shell si iti cere o parola, apoi niste detalii optionale (nume complet, telefoane) pe care le poti sari cu Enter, iar la final iti cere confirmarea. Alege o parola puternica si salveaz-o in managerul de parole. Chiar si dupa ce dezactivam login-ul cu parola prin SSH, asta e parola pe care o va cere sudo, deci in continuare conteaza.

Adauga utilizatorul in grupul sudo, care pe Debian si Ubuntu are dreptul sa foloseasca sudo din start:

usermod -aG sudo alex

Optiunile -aG inseamna “adauga in acest grup”. Daca uiti -a, utilizatorul e scos din toate celelalte grupuri, o greseala clasica. Verifica rezultatul:

groups alex

Trebuie sa vezi sudo in lista, de exemplu alex : alex sudo (pot aparea si alte grupuri, e in regula). Acum verificam ca sudo chiar functioneaza: trecem pe noul utilizator si intrebam sistemul cine suntem:

su - alex
sudo whoami

Prima data, sudo poate afisa un scurt mesaj despre responsabilitate, apoi cere [sudo] password for alex:. Dupa ce tastezi parola, raspunsul trebuie sa fie un singur cuvant: root. Asta dovedeste ca alex poate actiona ca root cand e nevoie. Scrie exit ca sa revii in shell-ul de root si pastreaza deschisa aceasta sesiune de root deocamdata.

De ce cheile SSH bat parolele

O parola e un secret pe care il trimiti serverului la fiecare login. Daca e scurta sau refolosita, un bot o poate ghici pana la urma, iar fiecare incercare nu il costa aproape nimic pe atacator. O cheie SSH functioneaza altfel: serverul trimite o provocare aleatoare, calculatorul tau o semneaza cu cheia privata, iar serverul verifica semnatura cu cheia publica pe care o are deja. Prin retea nu circula nimic refolosibil, iar cheia e atat de mare incat ghicirea ei nu e un atac realist.

Folosim tipul de cheie Ed25519: e modern, rapid, produce chei scurte si e suportat de orice versiune de OpenSSH pe care o vei intalni pe Debian 13 sau Ubuntu 24.04. RSA pe 3072 sau 4096 de biti merge si el, dar nu exista niciun motiv sa-l alegi pentru o cheie noua, decat daca un sistem vechi il cere.

Pasul 3: Generezi o cheie SSH pe calculatorul tau

Pasul asta se face pe calculatorul tau, nu pe server. Deschide o fereastra noua de terminal local si lasa sesiunea de pe server in pace.

Pe Linux si macOS

ssh-keygen -t ed25519 -C "alex@laptop"

Pe Windows 10 si 11

Deschide PowerShell (nu ai nevoie de drepturi de administrator) si ruleaza exact aceeasi comanda:

ssh-keygen -t ed25519 -C "alex@laptop"

In toate cazurile, -t ed25519 alege tipul cheii, iar -C adauga un comentariu, o eticheta care te ajuta sa recunosti cheia mai tarziu pe server. Unealta te intreaba unde sa salveze cheia: apasa Enter pentru locatia implicita (~/.ssh/id_ed25519, adica C:\Users\NumeleTau\.ssh\id_ed25519 pe Windows). Apoi iti cere un passphrase. Pune unul. El cripteaza cheia privata pe disc, asa ca un laptop furat sau un backup scapat pe undeva nu ofera automat acces la serverul tau. Putin mai jos vedem cum il tastezi o singura data pe sesiune.

La final ai doua fisiere:

• id_ed25519: cheia privata. Nu o copia niciodata pe un server, nu o trimite pe email sau pe chat.
• id_ed25519.pub: cheia publica, o singura linie care incepe cu ssh-ed25519. Pe asta o poti da linistit oricui.

Pasul 4: Copiezi cheia publica pe server

Serverul stie ce chei sunt permise dintr-un fisier numit ~/.ssh/authorized_keys, aflat in directorul personal al fiecarui utilizator. Fiecare linie din el e o cheie publica. Trebuie sa punem linia din fisierul tau .pub in /home/alex/.ssh/authorized_keys, cu proprietarul si permisiunile corecte.

Linux si macOS: ssh-copy-id

ssh-copy-id -i ~/.ssh/id_ed25519.pub alex@203.0.113.10

Iti cere parola lui alex pentru ultima data (deocamdata login-ul cu parola e inca permis) si ar trebui sa se termine cu:

Number of key(s) added: 1

ssh-copy-id creeaza folderul .ssh daca lipseste si seteaza singur permisiunile corecte.

Windows: o singura comanda in PowerShell

Windows nu vine cu ssh-copy-id, dar comanda asta din PowerShell face acelasi lucru:

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"

Citeste-o de la stanga la dreapta: type afiseaza cheia publica, pipe-ul | o trimite intr-o conexiune SSH, iar pe server cream folderul, adaugam cheia la authorized_keys si restrangem permisiunile. Modul 700 inseamna ca doar proprietarul poate intra in folder, iar 600 ca doar proprietarul poate citi si scrie fisierul.

Daca root se logheaza deja cu o cheie

Unele VPS-uri sunt livrate cu cheia ta SSH deja instalata pentru root. In cazul asta, din sesiunea de root de pe server, copiezi pur si simplu cheile autorizate ale lui root la noul utilizator:

mkdir -p /home/alex/.ssh
cp /root/.ssh/authorized_keys /home/alex/.ssh/
chown -R alex:alex /home/alex/.ssh
chmod 700 /home/alex/.ssh
chmod 600 /home/alex/.ssh/authorized_keys

Linia cu chown e cea importanta: daca fisierele raman ale lui root, sshd refuza sa le foloseasca pentru alex.

Pasul 5: Testezi login-ul cu cheie intr-un al doilea terminal

Acesta e pasul care te fereste sa ramai blocat afara. Nu inchide sesiunea de root. Deschide o fereastra de terminal complet noua pe calculatorul tau si conecteaza-te ca noul utilizator:

ssh alex@203.0.113.10

Daca ai pus passphrase, SSH ti-l cere (Enter passphrase for key ...). Asta inseamna deblocarea cheii locale, nu o parola de pe server. Daca ajungi la un prompt de tipul alex@vps:~$ fara sa ti se ceara parola lui alex de pe server, login-ul cu cheie functioneaza. Verifica si ca sudo merge in sesiunea asta:

sudo apt update

Daca ceva nu merge aici, opreste-te si citeste sectiunea de depanare de mai jos. Inca nu am oprit nimic, deci nu pierzi nimic daca repari acum.

Pasul 6: Dezactivezi login-ul root si autentificarea cu parola

Acum inchidem usile vechi. Atat Debian 13 cat si Ubuntu 24.04 citesc fisiere de configurare suplimentare din /etc/ssh/sshd_config.d/, ceea ce e mai curat decat sa editezi fisierul principal si rezista la actualizarile de pachete. Verifica faptul ca linia de include exista:

grep -i '^Include' /etc/ssh/sshd_config

Rezultatul asteptat: Include /etc/ssh/sshd_config.d/*.conf. Un detaliu subtil: pentru majoritatea setarilor, sshd foloseste prima valoare pe care o gaseste, iar fisierele din folder sunt citite in ordine alfabetica. Unele imagini Ubuntu vin cu un fisier numit 50-cloud-init.conf care seteaza PasswordAuthentication yes. De asta numele fisierului nostru incepe cu 01-: e citit primul si castiga:

sudo tee /etc/ssh/sshd_config.d/01-hardening.conf > /dev/null <<'EOF'
# Initial hardening: keys only, no direct root login
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF

Ce face fiecare linie:

• PermitRootLogin no: nimeni nu se mai poate loga prin SSH direct ca root, nici macar cu cheie. Munca de administrare trece prin alex si sudo.
• PasswordAuthentication no: serverul nu mai accepta parole prin SSH.
• KbdInteractiveAuthentication no: inchide calea “keyboard-interactive”, care pe unele sisteme e inca o metoda de a cere parola.
• PubkeyAuthentication yes: pastreaza login-ul cu cheie activ. E oricum valoarea implicita, o scriem explicit pentru claritate.

Inainte sa repornesti ceva, cere-i lui sshd sa verifice sintaxa:

sudo sshd -t

Daca nu afiseaza nimic, nu exista erori. Apoi uita-te la setarile pe care sshd le va folosi efectiv, dupa ce combina toate fisierele:

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|kbdinteractive'

Trebuie sa vezi:

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no

Daca vreuna inca spune yes, alt fisier il suprascrie pe al tau; le vezi cu ls /etc/ssh/sshd_config.d/. Cand totul arata bine, reporneste serviciul SSH. Atat pe Debian cat si pe Ubuntu, serviciul se numeste ssh:

sudo systemctl restart ssh

Repornirea lui sshd nu inchide sesiunile deja deschise, deci si fereastra de root si cea cu alex raman active. Acum, dintr-un al treilea terminal, demonstreaza ca usile vechi sunt chiar inchise:

ssh root@203.0.113.10
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password alex@203.0.113.10

Ambele trebuie refuzate cu Permission denied (publickey). Cuvantul din paranteza e lista metodelor pe care serverul le mai accepta: doar publickey. Apoi confirma inca o data ca un simplu ssh alex@203.0.113.10 functioneaza. Abia acum poti inchide linistit vechea sesiune de root.

Pasul 7: Pornesti un firewall de baza

In acest moment singurul serviciu pe care il vrem accesibil din internet e SSH, asa ca permitem portul 22 si blocam orice alta conexiune care vine din afara. Ubuntu foloseste UFW (Uncomplicated Firewall), iar acelasi pachet functioneaza perfect si pe Debian:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

UFW te avertizeaza ca s-ar putea sa intrerupa conexiunile SSH existente; pentru ca am permis deja 22/tcp, raspunzi cu y. Verifica rezultatul:

sudo ufw status verbose

Trebuie sa vezi Status: active, Default: deny (incoming), allow (outgoing) si o regula care permite 22/tcp. Cand vei instala mai tarziu un site, nu uita sa rulezi si sudo ufw allow 80/tcp si sudo ufw allow 443/tcp. O atentionare pentru viitor: porturile publicate de containerele Docker ocolesc regulile UFW, asa ca daca folosesti Docker, leaga serviciile interne de 127.0.0.1 in loc sa te bazezi doar pe firewall.

Mici extra care iti usureaza viata

O scurtatura in configuratia SSH

Ca sa nu mai tastezi IP-ul de fiecare data, creeaza (sau editeaza) fisierul ~/.ssh/config pe calculatorul tau. Pe Windows e C:\Users\NumeleTau\.ssh\config, fara extensie:

Host myvps
    HostName 203.0.113.10
    User alex
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

De acum, ssh myvps e suficient. IdentitiesOnly yes ii spune lui SSH sa ofere doar aceasta cheie, ceea ce evita eroarea “Too many authentication failures” cand ai mai multe chei pe acelasi calculator.

Passphrase-ul o singura data pe sesiune

Agentul SSH tine cheia deblocata in memorie, asa ca tastezi passphrase-ul o data, nu la fiecare conexiune. Pe macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 il salveaza si in Keychain. Pe majoritatea desktop-urilor Linux un agent ruleaza deja, deci ajunge ssh-add. Pe Windows, ruleaza o singura data intr-un PowerShell deschis ca administrator:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Apoi, intr-o fereastra PowerShell obisnuita, ruleaza ssh-add $env:USERPROFILE\.ssh\id_ed25519.

Fusul orar si actualizarile automate de securitate

Inapoi pe server, seteaza fusul orar corect ca orele din log-uri sa aiba sens, si lasa sistemul sa-si instaleze singur patch-urile de securitate:

sudo timedatectl set-timezone Europe/Bucharest
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Raspunde Yes cand esti intrebat daca vrei descarcarea si instalarea automata a actualizarilor stabile.

Depanare si greseli frecvente

“Permission denied (publickey)” pentru alex. Aproape mereu e o problema de proprietar sau de permisiuni. sshd e strict intentionat: daca ~/.ssh sau authorized_keys pot fi modificate de altcineva, le ignora. Din sesiunea de root (sau din consola web) ruleaza:

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

Apoi urmareste ce spune sshd in timp ce incerci sa te conectezi: sudo journalctl -u ssh -n 50 --no-pager. Linii precum Authentication refused: bad ownership or modes arata direct problema. Debian 13 nu mai scrie implicit /var/log/auth.log, asa ca journalctl e locul de incredere pe ambele sisteme.

Nu e oferita cheia buna. Ruleaza ssh -v alex@203.0.113.10 si citeste liniile care incep cu Offering public key. Daca cheia ta lipseste, adauga -i ~/.ssh/id_ed25519 sau foloseste linia IdentityFile din configuratia de mai sus.

“alex is not in the sudoers file”. Schimbarile de grup se aplica doar la login-urile noi, deci delogheaza-te si logheaza-te din nou. Daca tot nu merge, verifica daca ai scris usermod -aG sudo alex si nu alt nume de grup.

Login-ul cu parola merge si dupa Pasul 6. Alt fisier din folder castiga. Ruleaza sudo sshd -T | grep passwordauthentication, apoi sudo grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ ca sa gasesti vinovatul, si asigura-te ca fisierul tau e primul in ordine alfabetica.

“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” E normal dupa ce reinstalezi VPS-ul, pentru ca noul sistem si-a generat chei de host noi. Sterge amprenta veche cu ssh-keygen -R 203.0.113.10 si conecteaza-te din nou. Daca nu ai reinstalat nimic, opreste-te si afla de ce inainte sa tastezi vreo parola.

“ssh-copy-id is not recognized” pe Windows. Normal, foloseste comanda PowerShell din Pasul 4.

Ai ramas totusi blocat afara. Deschide consola web a VPS-ului din contul de client. Se comporta ca un monitor si o tastatura conectate direct la server si nu depinde de SSH. Logheaza-te acolo ca root cu parola (PermitRootLogin afecteaza doar SSH), repara fisierul sau permisiunile si ruleaza systemctl restart ssh.

Note de securitate

• Foloseste mereu un passphrase pe cheia privata si pastreaza o copie de rezerva in managerul de parole. Daca pierzi singura copie, vei avea nevoie de consola ca sa adaugi una noua.
• O cheie pentru fiecare dispozitiv. Genereaza chei separate pe laptop si pe desktop, fiecare cu un comentariu -C clar. Daca pierzi un dispozitiv, stergi doar linia lui din authorized_keys, iar celelalte merg mai departe.
• Nu seta sudo pe NOPASSWD pentru utilizatorul de zi cu zi. Parola de sudo e a doua bariera daca cineva ajunge vreodata in posesia cheii tale.
• Pastreaza parola de root, lunga si bine pastrata. Nu mai functioneaza prin SSH, dar iti trebuie pentru consola de urgenta.
• Schimbarea portului SSH nu e securitate. Mutarea SSH de pe 22 pe alt port reduce zgomotul botilor din log-uri, dar un scanner gaseste noul port in cateva secunde. Cu login doar pe chei, protectia reala e deja la locul ei. Unelte ca Fail2ban se pot adauga ulterior, mai ales ca sa ai log-uri mai curate.
• Uita-te din cand in cand cine se logheaza: last -n 20 arata ultimele login-uri, iar sudo journalctl -u ssh --since today arata activitatea SSH de azi.

Deci, e serverul tau pregatit?

Dupa aceste 30 de minute, VPS-ul tau are un cont personal cu sudo, login pe cheie pe care botii nu-l pot ghici, fara acces direct ca root, fara parole prin SSH si un firewall care lasa sa intre doar SSH. Asta e fundatia solida pe care o presupune orice alt tutorial de pe blog, fie ca urmeaza Docker, un server web sau o baza de date.

Daca nu ai inca un server, iti poti lua un VPS din data center-ul nostru din Romania si parcurgi ghidul asta la o cafea. Iar daca preferi ca altcineva sa-ti securizeze, sa-ti actualizeze si sa-ti supravegheze serverele, echipa noastra de administrare servere face exact asta in fiecare zi.

Intrebari frecvente

Ghidul e valabil si pentru Ubuntu 22.04 si Debian 12?

Da. Toate comenzile functioneaza si pe Ubuntu 22.04 si Debian 12. Folderul /etc/ssh/sshd_config.d/ exista pe ambele, iar serviciul se numeste tot ssh.

Folosesc chei Ed25519 sau RSA?

Ed25519 pentru orice cheie noua: mai scurta, mai rapida si sigura. Foloseste RSA (minim 3072 de biti) doar pentru sisteme foarte vechi care nu inteleg Ed25519.

Mai pot face lucruri ca root?

Da, prin sudo. sudo comanda ruleaza o singura comanda ca root, iar sudo -i deschide un shell complet de root cand ai nevoie de mai multe comenzi la rand. Scrie exit cand ai terminat.

Ce se intampla daca imi pierd laptopul?

Daca cheia are passphrase, hotul nu o poate folosi imediat. Logheaza-te de pe alt dispozitiv (sau din consola web), sterge din ~/.ssh/authorized_keys linia cu comentariul acelei chei si genereaza o cheie noua pe noul calculator.

Am nevoie de Fail2ban daca parolele sunt dezactivate?

Nu e obligatoriu pentru siguranta, pentru ca nu mai exista nicio parola de ghicit. Ramane util ca sa ai log-uri mai linistite si ca sa protejezi alte servicii, de exemplu un server de mail sau o pagina de login web.