Utilizatori, grupuri si sudo pe Linux: ghid practic

Mai devreme sau mai tarziu, VPS-ul tau nu mai e doar al tau. Un coleg trebuie sa faca deploy, un freelancer trebuie sa reporneasca un serviciu noaptea, un al doilea student intra in proiectul de licenta. Raspunsul rapid e sa dai parola de root sau sa bagi pe toata lumea in grupul sudo, iar exact asa ajung serverele mici sa aiba cinci oameni care pot face orice, nimeni care sa-si aminteasca cine a schimbat ce, si un fost colaborator a carui cheie SSH inca merge dupa un an. Linux are deja tot ce iti trebuie ca sa faci asta cum trebuie: utilizatori, grupuri si reguli sudo. In ghidul asta le luam pe toate trei, cu comenzi reale pe care le poti copia.

La final o sa stii sa creezi, sa blochezi si sa stergi conturi, sa adaugi un utilizator intr-un grup (inclusiv celebra cautare “linux add user to group sudo”), sa scrii reguli sudo limitate in /etc/sudoers.d/ care permit doar anumite comenzi, si sa configurezi un folder comun in care o echipa lucreaza fara batai de cap cu permisiunile. Totul e scris pentru Debian 13 si Ubuntu 24.04. Unde cele doua se comporta diferit, o spunem explicit.

De ce ai nevoie

• Un VPS (KVM sau LXC) cu Debian 13 sau Ubuntu 24.04.
• Un cont existent cu drepturi sudo, conectat prin SSH. Mai jos il numim “utilizatorul tau de admin”.
• O a doua sesiune SSH deschisa ca plasa de siguranta cat timp modifici reguli sudo, plus sa stii unde gasesti consola web sau modul rescue in zona de client, in caz ca te blochezi singur afara.
• Cam 30 de minute si confort de baza in terminal (scrii comenzi, editezi un fisier cu nano).

Daca esti pe Debian si ai setat o parola de root la instalare, se poate ca pachetul sudo sa nici nu fie instalat. Intra ca root si ruleaza intai apt install sudo. Imaginile noastre de VPS vin cu un utilizator care are deja sudo, deci majoritatea cititorilor pot sari peste pasul asta.

Cum gandeste Linux utilizatorii, grupurile si sudo

Inainte sa atingem ceva, cateva definitii, pentru ca fiecare comanda de mai jos se bazeaza pe ele.

Un utilizator e un cont cu un nume si un numar, UID-ul. Kernelul se uita doar la numar, numele e pentru oameni. root are mereu UID 0 si poate face orice. Conturile sub 1000 sunt utilizatori de sistem, creati de pachete ca sa ruleze servicii (www-data pentru serverul web, _apt pentru descarcarea pachetelor). Conturile pentru oameni incep de la 1000 pe Debian si Ubuntu.

Un grup e o multime de utilizatori cu nume si cu propriul numar, GID-ul. Fiecare utilizator are un grup principal (pe Debian si Ubuntu de obicei un grup privat cu acelasi nume ca utilizatorul) si oricate grupuri suplimentare, cum ar fi sudo sau devteam. Grupurile exista ca sa dai acces o singura data, grupului, nu fiecarei persoane in parte.

Informatiile astea stau in patru fisiere text simple:

• /etc/passwd: o linie per utilizator (nume, UID, GID, nume complet, director home, shell). Il poate citi oricine.
• /etc/shadow: hash-urile parolelor si datele de expirare. Il poate citi doar root.
• /etc/group: o linie per grup, cu membrii lui.
• /etc/gshadow: parole de grup, aproape niciodata folosite.

Fiecare fisier si director are un proprietar, un grup si trei seturi de permisiuni (citire r, scriere w, executie x) pentru proprietar, grup si restul lumii. Asa se transforma apartenenta la un grup in acces real.

In fine, sudo e programul care permite unui utilizator autorizat sa ruleze o comanda ca alt utilizator, de obicei root. Regulile lui stau in /etc/sudoers si in fisiere separate din /etc/sudoers.d/. Fiecare folosire a sudo e logata cu numele persoanei reale, si tocmai asta e ideea: stii cine a facut ce.

De ce sa nu dai pur si simplu parola de root?

Trei motive. Responsabilitate: daca patru oameni intra ca root, logurile spun doar “root a facut asta”. Revocare: cand cineva pleaca, trebuie sa schimbi parola si sa anunti pe toti ceilalti, in loc sa blochezi un singur cont. Privilegiu minim: majoritatea oamenilor au nevoie sa faca doua-trei lucruri ca root, nu orice. Un script de deploy care poate doar sa reincarce nginx nu poate sterge discul, nici din greseala, nici intentionat.

adduser sau useradd?

Debian si Ubuntu vin cu doua unelte pentru creat conturi, iar tutorialele le amesteca des:

Folosim adduser interactiv si aratam echivalentul cu useradd acolo unde conteaza.

Pasul 1: Verifici utilizatorii si grupurile existente

Te uiti mereu inainte sa schimbi ceva. Listeaza doar conturile pentru oameni (UID de la 1000 in sus, fara nobody, care are 65534):

getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 { print $1, $3, $6, $7 }'

getent citeste baza de date de conturi (fisierele de mai sus, plus orice serviciu de director), iar awk afiseaza numele, UID-ul, directorul home si shell-ul. Pe un VPS proaspat ar trebui sa vezi o singura linie, utilizatorul tau de admin, ceva de genul cristian 1000 /home/cristian /bin/bash.

Acum vezi cine are deja drepturi sudo complete si din ce grupuri faci parte tu:

getent group sudo
id

Prima comanda afiseaza sudo:x:27:cristian: numele grupului, GID-ul (27 pe Debian si Ubuntu) si membrii. id iti arata UID-ul, grupul principal si toate grupurile suplimentare. Pe Ubuntu, primul utilizator e adesea si in adm, cdrom, dip, plugdev si uneori lxd. Tine minte lxd, revenim la el in sectiunea de securitate.

Nu te speria cat de lungi sunt listele complete. Ruleaza getent passwd | wc -l si getent group | wc -l si o sa vezi zeci de intrari chiar si pe un server nou-nout. Sunt conturi si grupuri de sistem create de pachete, si le lasi in pace.

Pasul 2: Creezi un utilizator

Hai sa cream un cont pentru o colega, alice:

sudo adduser alice

adduser creeaza utilizatorul alice si un grup privat alice, face directorul /home/alice, copiaza fisierele implicite din /etc/skel, apoi iti cere parola de doua ori si niste detalii optionale (nume complet, camera si altele, apesi Enter ca sa le sari). La final intreaba “Is the information correct? [Y/n]”, raspunzi Y.

Echivalentul neinteractiv, util in scripturi, e:

sudo useradd -m -s /bin/bash -c "Alice Popescu" alice
sudo passwd alice

Aici -m creeaza directorul home, -s seteaza shell-ul si -c pastreaza numele complet. Fara -s, useradd poate da contului /bin/sh, care merge, dar e neplacut de folosit interactiv.

Verifici rezultatul si permisiunile directorului home:

getent passwd alice
ls -ld /home/alice

O sa vezi o linie de forma alice:x:1001:1001:Alice Popescu,,,:/home/alice:/bin/bash. x-ul inseamna ca hash-ul real al parolei e in /etc/shadow. La directorul home, versiunile recente de adduser creeaza home-uri private (drwx------ sau drwxr-x---, in functie de versiune si de DIR_MODE din /etc/adduser.conf), iar useradd urmeaza HOME_MODE sau UMASK din /etc/login.defs. Daca vezi drwxr-xr-x, ceilalti utilizatori pot rasfoi fisierele lui alice, asa ca strange permisiunile cu sudo chmod 750 /home/alice.

Ii dai utilizatorului o cheie SSH

Parolele pe SSH sunt tinta botilor, cheile sunt mult mai sigure. Cere-i lui alice cheia publica (fisierul .pub, niciodata pe cea privata) si instaleaz-o:

sudo install -d -m 700 -o alice -g alice /home/alice/.ssh
echo "ssh-ed25519 AAAAC3Nza...inlocuieste-cu-cheia-reala alice@laptop" | sudo tee -a /home/alice/.ssh/authorized_keys
sudo chown alice:alice /home/alice/.ssh/authorized_keys
sudo chmod 600 /home/alice/.ssh/authorized_keys

install -d creeaza directorul .ssh cu proprietarul si permisiunile corecte dintr-o miscare. tee -a adauga cheia la final (un simplu > nu ar merge prin sudo). SSH e strict: daca .ssh sau authorized_keys poate fi scris de altcineva, ignora cheia fara sa te anunte.

Doua variante utile. Daca persoana va intra doar cu cheie, creezi contul cu sudo adduser --disabled-password alice: nu se seteaza nicio parola. Retine ca un astfel de utilizator nu poate trece de cererea de parola a sudo, lucru care conteaza la Pasul 4. Iar daca setezi o parola temporara, fortezi schimbarea ei la prima autentificare cu sudo passwd --expire alice.

Pasul 3: Adaugi utilizatorul in grupuri (linux add user to group sudo)

Asta e pasul pe care il cauta cei mai multi. Ca sa-i dai lui alice drepturi complete de admin, o adaugi in grupul sudo:

sudo usermod -aG sudo alice

-G seteaza grupurile suplimentare, iar -a inseamna adauga (append). -a e esential: usermod -G sudo alice fara el inlocuieste toate grupurile suplimentare ale lui alice doar cu sudo, scotand-o in liniste din toate celelalte. Doua comenzi echivalente care nu pot face greseala asta:

sudo gpasswd -a alice sudo
# sau, doar pe Debian/Ubuntu:
sudo adduser alice sudo

Verifici:

id alice

Rezultat asteptat: uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo). Apartenenta la grupuri se citeste la login, deci daca alice e deja conectata, trebuie sa iasa si sa intre din nou ca sa-i mearga sudo. Testul din partea ei e sudo whoami, care ar trebui sa afiseze root dupa ce ii cere propria parola (nu pe cea de root). Din contul tau de admin poti verifica fara sa intri ca ea: sudo -l -U alice ar trebui sa listeze (ALL : ALL) ALL.

Ca sa retragi dreptul:

sudo gpasswd -d alice sudo

Pe distributiile din familia Red Hat grupul de admin se numeste wheel, nu sudo. Pe Debian si Ubuntu e sudo.

Creezi si stergi grupuri

Grupurile tale functioneaza la fel. Creeaza unul pentru echipa pe care o folosim la Pasul 5:

sudo groupadd devteam
getent group devteam

Rezultatul devteam:x:1002: arata un grup nou, gol. Stergi un grup cu sudo groupdel devteam; Linux refuza daca e inca grupul principal al cuiva.

O cale de mijloc utila intre “nimic” si “root complet”: apartenenta la adm permite citirea majoritatii logurilor din /var/log, iar systemd-journal permite citirea intregului jurnal de sistem, ambele fara sudo.

Pasul 4: Dai drepturi sudo limitate cu sudoers.d

Sudo complet e in regula pentru admini. Pentru restul scriem reguli inguste. O regula sudoers se citeste ca o propozitie:

cine  unde=(ca_cine)   comenzi
%sudo ALL=(ALL:ALL)    ALL

Linia implicita de mai sus spune: membrii grupului sudo (% inseamna grup), pe orice host, pot rula ca orice utilizator si grup, orice comanda. O gasesti in /etc/sudoers, impreuna cu linia @includedir /etc/sudoers.d (sistemele mai vechi scriu #includedir, care nu e comentariu, desi incepe cu #). Linia asta e motivul pentru care nu editam niciodata /etc/sudoers direct: punem fisiere separate in /etc/sudoers.d/, cate unul pentru fiecare scop, ca sa fie usor de verificat si de sters.

Inainte sa editezi ceva, deschide un al doilea terminal si ruleaza sudo -i in el. Shell-ul de root ramane deschis chiar daca strici sudo, asa ca iti poti repara imediat greseala.

O regula pentru un utilizator de deploy

Sa zicem ca un pipeline CI intra ca deploy si are nevoie sa testeze si sa reincarce nginx, nimic altceva. Creezi utilizatorul fara parola (va folosi o cheie SSH) si afli caile exacte ale comenzilor:

sudo adduser --disabled-password deploy
command -v systemctl nginx

De obicei rezultatul e /usr/bin/systemctl si /usr/sbin/nginx. Sudo potriveste comenzile dupa calea completa, asa ca le copiezi mereu din acest rezultat. Acum creezi fisierul de reguli cu visudo, care verifica sintaxa inainte sa salveze:

sudo visudo -f /etc/sudoers.d/deploy-nginx

Se deschide editorul implicit (de obicei nano). Lipeste:

# Let the deploy user test and reload nginx, nothing else
Cmnd_Alias DEPLOY_NGINX = /usr/sbin/nginx -t, /usr/bin/systemctl reload nginx, /usr/bin/systemctl restart nginx
deploy ALL=(root) NOPASSWD: DEPLOY_NGINX

Cmnd_Alias da un nume unei liste de comenzi (cu majuscule si unic in toate fisierele sudoers). Pentru ca am scris si argumentele, deploy poate rula exact aceste linii de comanda: systemctl stop nginx sau systemctl restart ssh sunt refuzate. O comanda trecuta fara argumente ar permite orice argumente, deci fii mereu specific. NOPASSWD e necesar aici pentru ca deploy nu are parola; pentru oameni, e mai bine sa-l lasi deoparte.

Salveaza si iesi. Apoi validezi tot si verifici permisiunile:

sudo visudo -c
sudo ls -l /etc/sudoers.d/

Vrei sa vezi parsed OK pentru /etc/sudoers si pentru fiecare fisier din sudoers.d, plus modul -r--r----- root root (0440). Daca modul e altul, il corectezi cu sudo chmod 0440 /etc/sudoers.d/deploy-nginx.

Testezi ca utilizatorul deploy:

sudo -l -U deploy
sudo -iu deploy
sudo systemctl reload nginx      # permis
sudo systemctl stop nginx        # refuzat
exit

sudo -l -U deploy afiseaza regulile, terminand cu (root) NOPASSWD: /usr/sbin/nginx -t, /usr/bin/systemctl reload nginx, /usr/bin/systemctl restart nginx. Comanda refuzata raspunde cu “Sorry, user deploy is not allowed to execute … as root”. Daca nu ai nginx instalat pe VPS, foloseste un serviciu pe care chiar il rulezi. Pentru citirea starii nu ai nevoie de sudo deloc: systemctl status nginx merge pentru orice utilizator.

O regula pentru un grup, cu sudoedit

Regulile pe grupuri scaleaza mai bine decat cele pe persoane. Aici membrii webadmins pot reincarca nginx si pot edita configuratia principala:

sudo groupadd webadmins
sudo usermod -aG webadmins bob
sudo visudo -f /etc/sudoers.d/webadmins

%webadmins ALL=(root) /usr/bin/systemctl reload nginx, sudoedit /etc/nginx/nginx.conf

sudoedit e modul sigur de a lasa pe cineva sa editeze un fisier al lui root: sudo copiaza fisierul intr-o locatie temporara, bob editeaza copia cu propriul editor, rulat ca bob, iar sudo o scrie inapoi. Daca ai da in schimb sudo nano /etc/nginx/nginx.conf, editorul ar rula ca root, iar editoarele pot deschide alte fisiere sau pot rula comenzi de shell. Bob il foloseste ca sudoedit /etc/nginx/nginx.conf.

Comenzi pe care nu le dai niciodata

Orice comanda care poate scrie fisiere arbitrare sau poate porni alte programe echivaleaza cu root complet. Asta include shell-uri (bash, sh), editoare (vim, nano), pagere (less, more), find, tar, rsync, cp, mv, chmod, chown, interpretoare (python3, perl), docker, managerii de pachete (apt install ruleaza scripturile pachetelor) si systemctl edit. Si wildcard-urile in argumente (/usr/bin/systemctl * nginx) sunt periculoase, pentru ca * poate prinde argumente in plus.

Pasul 5: Configurezi un folder comun pentru echipa

alice si bob au nevoie de un folder in care amandoi sa poata crea si edita fisiere, iar nimeni altcineva sa nu se poata uita inauntru. Permisiunile clasice te duc 90% din drum, un ACL rezolva restul.

sudo usermod -aG devteam alice
sudo usermod -aG devteam bob
sudo mkdir -p /srv/projects/devteam
sudo chown root:devteam /srv/projects/devteam
sudo chmod 2770 /srv/projects/devteam

/srv e locul standard pentru datele servite de masina. Modul 2770 inseamna: proprietarul si grupul pot citi, scrie si intra (77), restul nu primesc nimic (0), iar 2-ul din fata seteaza bitul setgid. Pe un director, setgid face ca fiecare fisier si subfolder nou sa apartina grupului devteam, nu grupului privat al celui care l-a creat.

Mai ramane o capcana: umask-ul. E o masca per proces care scoate permisiuni de la fisierele noi, iar valoarea implicita obisnuita, 022, scoate dreptul de scriere pentru grup. Deci fisierele noi ale lui alice ar putea fi citite de bob, dar nu si editate. In loc sa schimbam umask-ul tuturor, setam un ACL implicit (Access Control List, lista de control al accesului) pe folder, care are prioritate fata de umask pentru tot ce se creeaza inauntru:

sudo apt install -y acl
sudo setfacl -m g:devteam:rwx /srv/projects/devteam
sudo setfacl -d -m g:devteam:rwx,o::--- /srv/projects/devteam
getfacl /srv/projects/devteam

Primul setfacl da explicit acces grupului, al doilea (-d) defineste valorile implicite mostenite de fisierele si folderele noi. Rezultatul getfacl ar trebui sa contina group:devteam:rwx, default:group:devteam:rwx si default:other::---, plus # flags: -s- pentru bitul setgid.

Testezi folosind sudo -u ca sa actionezi ca fiecare utilizator (sudo incarca grupurile proaspat, deci merge chiar inainte ca ei sa se reconecteze):

sudo -u alice touch /srv/projects/devteam/notes.txt
sudo -u bob sh -c 'echo "edited by bob" >> /srv/projects/devteam/notes.txt'
sudo ls -l /srv/projects/devteam

Rezultat asteptat: -rw-rw----+ 1 alice devteam 14 ... notes.txt. Proprietar alice, grup devteam, grupul poate scrie, ceilalti nimic, iar editarea lui bob a reusit. Daca vrei sa-i opresti si sa-si stearga fisierele unul altuia, adaugi sticky bit cu sudo chmod +t /srv/projects/devteam (modul devine 3770).

O nota pentru containere: toate astea merg si intr-un container LXC neprivilegiat, pentru ca utilizatorii si grupurile traiesc in interiorul containerului. Pe unele configuratii de stocare, mai ales bind mount-uri de pe host, setfacl poate da eroarea “Operation not supported”. In cazul asta pastrezi folderul cu setgid si ii rogi pe membrii echipei sa puna umask 002 in ~/.bashrc.

Pasul 6: Blochezi temporar un utilizator

Cineva pleaca in concediu sau banuiesti ca un cont a fost compromis. Vrei sa blochezi accesul fara sa stergi nimic. Greseala frecventa e sudo passwd -l alice: dezactiveaza doar parola, iar alice poate intra in continuare cu cheia SSH. Chiar manualul usermod recomanda combinarea blocarii parolei cu o data de expirare:

sudo usermod -L -e 1 alice

-L blocheaza parola, iar -e 1 seteaza expirarea contului in ziua 1 dupa 1 ianuarie 1970, deci contul e considerat expirat. Prin PAM, pe care il folosesc si SSH si cron, un cont expirat nu se mai poate autentifica nici cu parola, nici cu cheie, iar joburile lui cron de regula nu mai ruleaza nici ele.

Blocarea nu inchide sesiunile deja deschise. Le inchizi tu:

sudo loginctl terminate-user alice
pgrep -u alice || echo "no processes left"

Daca raman procese (sau loginctl nu exista in containerul tau), folosesti sudo pkill -u alice. Verifici blocarea:

sudo passwd -S alice
sudo chage -l alice

passwd -S arata L in a doua coloana (blocat), iar chage -l arata “Account expires: Jan 02, 1970”. Ca sa deblochezi mai tarziu:

sudo usermod -U -e "" alice

Un -e "" gol scoate data de expirare. La conturile doar cu cheie, fara parola, usermod -U poate avertiza ca deblocarea ar lasa un cont fara parola; e in regula, schimbarea expirarii e cea care reda accesul.

Pasul 7: Stergi un utilizator in siguranta

Stergerea e definitiva, asa ca o faci in ordinea asta: blochezi (Pasul 6), te uiti in jur, faci backup, stergi, verifici ce a ramas. Intai vezi ce lasa alice in urma in afara home-ului:

sudo crontab -u alice -l
sudo find / -xdev -user alice -not -path "/home/alice/*" 2>/dev/null
sudo grep -rl alice /etc/sudoers.d/

Prima comanda arata joburile programate (“no crontab for alice” e vestea buna). find cauta pe sistemul de fisiere radacina (-xdev ramane pe el) fisiere detinute de ea in alte locuri, de exemplu in /srv/projects/devteam. Fisierele comune ale echipei le predai de obicei cu sudo chown bob <fisier>. grep gaseste fisierele sudoers care o pomenesc, pe care le stergi sau le editezi cu visudo.

Faci backup la directorul home si iti asumi arhiva, pentru ca sudo tar creeaza fisiere detinute de root:

sudo tar -czf ~/alice-home-$(date +%F).tar.gz -C /home alice
sudo chown "$USER": ~/alice-home-*.tar.gz

O copiezi de pe server din calculatorul tau cu scp adminul-tau@ip-vps:~/alice-home-*.tar.gz .. Acum stergi contul si directorul home:

sudo deluser --remove-home alice
id alice

Echivalentul portabil e sudo userdel -r alice. Ambele refuza cat timp utilizatorul mai are procese pornite, de asta le-am oprit la Pasul 6. id alice ar trebui sa raspunda acum “no such user”. La final cauti fisiere orfane: sudo find / -xdev -nouser listeaza fisierele al caror proprietar nu mai exista. Ele apar cu un numar in loc de nume, iar un utilizator viitor care primeste acelasi UID le-ar mosteni fara sa stie, asa ca le reatribui sau le stergi.

Depanare si greseli frecvente

• Utilizatorul si-a pierdut toate grupurile. Ai rulat usermod -G fara -a. Readaugi grupurile cu sudo usermod -aG grup1,grup2 alice si verifici cu id alice.
• “Permission denied” imediat dupa ce ai adaugat pe cineva intr-un grup. Grupurile se incarca la login. Iesi si intra din nou, sau pornesti un shell nou cu grupul folosind newgrp devteam.
• Un fisier din sudoers.d e ignorat. Sudo sare peste fisierele care au punct in nume sau se termina cu ~. deploy.conf e ignorat, deploy-nginx merge. Verifica si modul 0440.
• “alice is not in the sudoers file”. Nu e inca in grupul sudo, sau nu s-a reconectat de cand ai adaugat-o.
• sudo cere parola unui utilizator care are doar cheie. Utilizatorul nu are parola. Fie ii setezi una cu sudo passwd deploy, fie dai doar comenzi precise cu NOPASSWD.
• O regula nu se potriveste. Probabil calea e alta. Rulezi command -v si copiezi calea exacta, si tii minte ca argumentele din regula trebuie sa se potriveasca exact.
• Ai stricat sudo. Folosesti shell-ul de root lasat deschis in al doilea terminal si rulezi visudo -c. Daca l-ai inchis, folosesti su - daca exista parola de root, altfel consola web sau modul rescue din zona de client ca sa repari fisierul.
• Unde sunt logurile sudo? Pe Ubuntu 24.04 sunt in /var/log/auth.log si in jurnal. Debian 13 nu instaleaza rsyslog implicit, deci nu exista auth.log: folosesti sudo journalctl _COMM=sudo --since today, care merge pe ambele.

Note de securitate

• Privilegiu minim din start. Sudo complet doar pentru oamenii care chiar administreaza serverul; restul primesc un fisier ingust in /etc/sudoers.d/.
• Unele grupuri sunt root deghizat. Apartenenta la docker, lxd sau disk ii da unui utilizator control total asupra masinii, fara nicio cerere de parola sudo. Trateaza adaugarea cuiva in aceste grupuri exact ca adaugarea in sudo.
• Foloseste mereu visudo, si pentru fisierul principal, si pentru cele din sudoers.d. O eroare de sintaxa intr-un fisier editat direct poate dezactiva sudo pentru toata lumea.
• Auditeaza regulat. getent group sudo, ls /etc/sudoers.d/ si sudo -l -U <utilizator> iti arata cine ce poate face in mai putin de un minut. Combina-le cu lista conturilor umane din Pasul 1, la cateva luni.
• Retragi accesul in aceeasi zi. Blochezi (Pasul 6) imediat ce cineva pleaca, stergi (Pasul 7) dupa ce ai luat ce iti trebuie din fisierele lui.
• Scurteaza perioada de gratie a sudo daca mai multi oameni folosesc serverul: un fisier ca /etc/sudoers.d/00-defaults cu Defaults timestamp_timeout=5 cere parola din nou dupa 5 minute, in loc de cele 15 implicite.
• Prefera cheile SSH pentru toate conturile si ia in calcul dezactivarea autentificarii cu parola si a login-ului direct ca root prin SSH, dupa ce fiecare admin are o cheie si sudo functionale.

Deci, de cat acces are nevoie de fapt fiecare?

De obicei de mult mai putin decat “de tot”. Cu cei sapte pasi de mai sus poti aduce un om nou, ii dai exact drepturile de care are nevoie pentru munca lui, imparti fisiere cu o echipa curat si iei totul inapoi in ziua in care pleaca, totul cu unelte deja instalate pe orice server Debian si Ubuntu. Cinci minute petrecute scriind un fisier in sudoers.d, in loc sa dai root complet, te scutesc de ore de ghicit dupa primul incident.

Poti incerca toate comenzile din ghid pe un VPS de la noi, cu acces root din primul minut. Daca preferi ca altcineva sa configureze conturile, politicile sudo, cheile SSH si auditurile periodice de acces pentru echipa ta, serviciul nostru de administrare servere se ocupa de asta.

Intrebari frecvente

Cum adaug un utilizator in grupul sudo pe Ubuntu sau Debian?

Rulezi sudo usermod -aG sudo utilizator, apoi ii ceri utilizatorului sa iasa si sa intre din nou. Verifici cu id utilizator. Nu uita niciodata -a, altfel utilizatorul pierde celelalte grupuri suplimentare.

Care e diferenta dintre adduser si useradd?

adduser e o unealta prietenoasa din Debian/Ubuntu care creeaza directorul home, seteaza bash si cere parola. useradd e unealta de nivel jos disponibila pe orice distributie si are nevoie de optiuni precum -m si -s /bin/bash ca sa obtii acelasi rezultat.

De ce nu merge grupul nou pana nu ma deconectez?

Grupurile se citesc cand porneste o sesiune. Shell-urile existente pastreaza lista veche. Iesi si intra din nou, sau folosesti newgrp numegrup pentru un singur shell.

Este NOPASSWD sigur?

E acceptabil pentru conturi de automatizare restranse la cateva comenzi exacte. Pentru oameni cu drepturi largi, pastreaza cererea de parola: te protejeaza daca cineva pune mana pe o sesiune lasata deschisa.

Ce este grupul wheel?

E grupul traditional de admin pe distributiile din familia Red Hat si joaca rolul pe care il are grupul sudo pe Debian si Ubuntu.