Acces la server pentru colegi și dezvoltatori externi

Ghidul arată cum dați acces la server unui coleg sau unui dezvoltator extern fără să împărțiți contul blackbox.md, parola root sau token-urile API. Cheia colegului pentru root o adăugați în panoul app.blackbox.md, pe cardul serverului din „Serverele mele” (app.blackbox.md/my-servers, meniul din stânga „Infrastructură” → „Serverele mele”). Utilizatorii separați și accesul doar prin SFTP se configurează pe server, prin SSH, ca root.

Disponibil pentru: titularul contului blackbox.md care a comandat serverul sau un cont căruia BLACKBOX i-a acordat drept de administrare pentru server (pașii din panou) și oricine are acces root prin SSH la server (pașii de pe server). Pe cardurile marcate „Administrat” butoanele „Adaugă cheie SSH” și „Resetează parola” nu apar; pentru aceste servere scrieți-ne.

Ce există în cont și în panou

• Contul blackbox.md și panoul nu au membri de echipă, sub-utilizatori, roluri sau invitații trimise de clienți. Fiecare persoană folosește propriul cont blackbox.md.
• Un coleg cu cont propriu nu vede comenzile, facturile, tichetele sau serverele dvs. și nu intră în panou în locul dvs. Pentru acces prin SSH sau SFTP nu are nevoie de cont.
• Accesul comun la serverele unei companii administrate de BLACKBOX (cardurile „Administrat”) se acordă doar la cerere, prin suport: Pagina „Prezentare generală” (Overview).
• Lista „Chei instalate” și butonul „Adaugă cheie SSH” lucrează doar cu fișierul /root/.ssh/authorized_keys. Cheile altor utilizatori Linux le gestionați direct pe server.

Ce nu împărțiți niciodată

Conform Termenilor și condițiilor (§3), răspundeți integral pentru activitatea tuturor persoanelor pe care le autorizați să acceseze serviciile (angajați, contractori) și pentru securizarea parolelor, cheilor SSH și token-urilor API.

Colegul își generează propria pereche de chei (Generarea unei chei SSH (Windows, macOS, Linux)) și vă trimite doar cheia publică: o singură linie din fișierul .pub. Rugați-l să-și pună numele în comentariul cheii, ca s-o recunoașteți în „Chei instalate”:

ssh-keygen -t ed25519 -C "NUME_COLEG"

Cereți-i și amprenta cheii, ca s-o comparați cu cea instalată pe server. Pe macOS și Linux:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Pe Windows (PowerShell):

ssh-keygen -lf $env:USERPROFILE\.ssh\id_ed25519.pub

Ce acces alegeți

Cheia colegului pentru root, din panou

1. Pe cardul serverului din „Serverele mele”, apăsați „Adaugă cheie SSH”.

2. Alegeți „Lipește o cheie nouă” și lipiți linia primită de la coleg (ssh-ed25519 AAAA… NUME_COLEG).

3. Apăsați „Adaugă cheia”. Apare „Cheie adăugată.”, iar cheia apare în „Chei instalate”, cu comentariul ei.

4. Comparați începutul amprentei din listă cu amprenta trimisă de coleg.

5. Colegul se conectează:

   ssh root@IP_SERVER

Cheia lipită se instalează doar pe acest server și nu se salvează în contul dvs. Lista și mesajele ei: Adăugarea și ștergerea cheilor SSH pe server.

Important O cheie pentru root înseamnă control total: colegul poate citi toate datele, poate adăuga alte chei și utilizatori și poate schimba orice setare. Rugați-l să nu șteargă „Cheie de administrare (blackbox.md)” și să nu seteze PermitRootLogin no: oricare dintre aceste acțiuni oprește resetarea parolei, gestionarea cheilor și butoanele de autentificare cu parolă din panou (Cheile BLACKBOX de pe serverul dvs.).

Utilizator Linux separat pentru coleg

Un utilizator separat are login propriu: în jurnale apar numele lui și comenzile rulate cu sudo. Pașii seamănă cu pasul 5 din Securizarea unui server nou: lista de verificare, dar pe server ajunge cheia colegului, nu cheile lui root. Rulați comenzile ca root.

Ubuntu și Debian

adduser --disabled-password NUME_UTILIZATOR

Comanda creează și directorul /home/NUME_UTILIZATOR. Câmpurile cerute (nume complet, telefon etc.) le puteți lăsa goale. Utilizatorul nu are parolă și se conectează doar cu cheia.

AlmaLinux și CentOS Stream

useradd -m NUME_UTILIZATOR

Nici aici utilizatorul nu primește parolă: se conectează doar cu cheia.

Cheia publică a colegului

1. Creați directorul și deschideți fișierul cheilor:

   mkdir -p /home/NUME_UTILIZATOR/.ssh
   nano /home/NUME_UTILIZATOR/.ssh/authorized_keys

   Dacă nano lipsește (se poate întâmpla pe AlmaLinux și CentOS Stream), instalați-l:

   dnf install -y nano

2. Lipiți pe un singur rând cheia publică a colegului, salvați cu Ctrl + O și Enter, apoi ieșiți cu Ctrl + X.

3. Setați proprietarul și drepturile:

   chown -R NUME_UTILIZATOR:NUME_UTILIZATOR /home/NUME_UTILIZATOR/.ssh
   chmod 700 /home/NUME_UTILIZATOR/.ssh
   chmod 600 /home/NUME_UTILIZATOR/.ssh/authorized_keys

   Pe AlmaLinux și CentOS Stream refaceți și eticheta SELinux:

   restorecon -R /home/NUME_UTILIZATOR/.ssh

4. Comparați amprenta afișată cu cea trimisă de coleg:

   ssh-keygen -lf /home/NUME_UTILIZATOR/.ssh/authorized_keys

Nu copiați /root/.ssh/authorized_keys la utilizatorul nou: acolo sunt cheile dvs. și cheile BLACKBOX.

Drepturi de administrare (doar dacă sunt necesare)

Membrii grupului sudo (Ubuntu, Debian) sau wheel (AlmaLinux, CentOS Stream) pot rula orice comandă ca root. sudo cere parola utilizatorului, așa că setați-i una.

Ubuntu și Debian:

passwd NUME_UTILIZATOR
usermod -aG sudo NUME_UTILIZATOR

Pe Debian, dacă lipsește comanda sudo, instalați-o:

apt install -y sudo

AlmaLinux și CentOS Stream:

passwd NUME_UTILIZATOR
usermod -aG wheel NUME_UTILIZATOR

Transmiteți parola separat de restul datelor de acces și rugați colegul s-o schimbe cu passwd la prima conectare. Pe un server „Parolă + cheie”, cu această parolă colegul s-ar putea conecta și prin SSH; trecerea la „Doar cheie”: Activarea și dezactivarea autentificării SSH cu parolă. Comenzile rulate cu sudo le vedeți în jurnal:

journalctl _COMM=sudo

Prima conectare

Testați conectarea împreună cu colegul înainte să-i predați accesul, cu sesiunea dvs. root deschisă. În ea urmăriți jurnalul SSH. Pe Ubuntu și Debian:

journalctl -u ssh -f

Pe AlmaLinux și CentOS Stream:

journalctl -u sshd -f

Colegul se conectează:

ssh NUME_UTILIZATOR@IP_SERVER

În jurnal apare o linie Accepted publickey for NUME_UTILIZATOR, cu amprenta cheii; opriți urmărirea cu Ctrl + C. Dacă i-ați dat drepturi de administrare, colegul rulează comanda de mai jos, care trebuie să afișeze root:

sudo whoami

Pe un server „Doar cheie”, colegul se conectează doar cu cheia. Nu reactivați autentificarea cu parolă pentru el: „Activează login cu parolă” o pornește pentru toți utilizatorii, inclusiv root.

Doar baza de date

Creați utilizatorul ca mai sus, fără drepturi de administrare. Ca el să poată deschide doar tunelul, nu și un terminal:

usermod -s /usr/sbin/nologin NUME_UTILIZATOR

Colegul pornește tunelul cu numele lui de utilizator (pentru PostgreSQL, înlocuiți 3306 cu 5432):

ssh -N -L 3306:127.0.0.1:3306 NUME_UTILIZATOR@IP_SERVER

Tunelul trece prin portul SSH (22), deci portul bazei de date nu trebuie deschis. În baza de date creați-i un utilizator separat, doar cu drepturile de care are nevoie: Baze de date: MariaDB/MySQL și PostgreSQL.

Acces doar prin SFTP la fișierele site-ului (opțional)

Colegul poate doar încărca și descărca fișiere în directorul site-ului: nu primește terminal și nu poate deschide tuneluri. Exemplul presupune site-ul în /var/www/DOMENIU. SSH îl limitează pe coleg la directorul /srv/sftp/NUME_UTILIZATOR, care aparține lui root și pe care colegul nu îl poate modifica. În el, subdirectorul site arată directorul site-ului, unde colegul poate scrie.

Pe planurile „VPS hosting”, întrebați întâi suportul: panoul de control de pe server poate avea propriile conturi și setări SFTP (Planurile „VPS hosting” cu panou de control).

Atenție Pașii 4 și 5 modifică setările SSH. Păstrați deschisă sesiunea root curentă până vă conectați din nou ca root dintr-un terminal nou. Clienții nu au consolă web sau VNC: dacă pierdeți accesul SSH, vă poate ajuta doar suportul.

1. Creați grupul (o singură dată, pentru toți utilizatorii SFTP) și utilizatorul.

   Ubuntu și Debian:

   groupadd sftponly
   adduser --disabled-password --shell /usr/sbin/nologin NUME_UTILIZATOR
   usermod -aG sftponly NUME_UTILIZATOR

   AlmaLinux și CentOS Stream:

   groupadd sftponly
   useradd -m -s /usr/sbin/nologin -G sftponly NUME_UTILIZATOR

   Adăugați apoi cheia colegului ca în secțiunea „Cheia publică a colegului” de mai sus.

2. Creați directorul colegului și faceți o copie a fișierului /etc/fstab:

   mkdir -p /srv/sftp/NUME_UTILIZATOR/site
   chown root:root /srv/sftp /srv/sftp/NUME_UTILIZATOR
   chmod 755 /srv/sftp /srv/sftp/NUME_UTILIZATOR
   cp /etc/fstab /etc/fstab.bak
   nano /etc/fstab

   La sfârșitul fișierului /etc/fstab adăugați linia de mai jos și salvați:

   /var/www/DOMENIU /srv/sftp/NUME_UTILIZATOR/site none bind,nofail 0 0

   Montați directorul site-ului și verificați că vedeți fișierele lui:

   systemctl daemon-reload
   mount /srv/sftp/NUME_UTILIZATOR/site
   ls /srv/sftp/NUME_UTILIZATOR/site

   Linia din /etc/fstab refăce montarea după fiecare repornire. Cu nofail, o greșeală în ea nu oprește pornirea serverului.

3. Permiteți scrierea în site. Fișierele site-ului trebuie să aparțină utilizatorului serverului web: Transferul fișierelor pe server (scp, rsync, SFTP), secțiunea „După încărcarea unui site: proprietarul și permisiunile”. Aflați grupul lor:

   stat -c '%U:%G' /var/www/DOMENIU

   De regulă rezultatul este www-data:www-data pe Ubuntu și Debian și apache:apache sau nginx:nginx pe AlmaLinux și CentOS Stream. Dacă vedeți root:root, schimbați întâi proprietarul ca în secțiunea indicată. Apoi rulați comenzile de mai jos, cu grupul de după : în loc de GRUP_WEB:

   usermod -aG GRUP_WEB NUME_UTILIZATOR
   chmod -R g+w /var/www/DOMENIU
   find /var/www/DOMENIU -type d -exec chmod g+s {} +

   Fișierele încărcate de coleg îi aparțin lui și grupului serverului web, care le poate citi. Dacă aplicația trebuie să le și modifice, refaceți proprietarul ca în ghidul de transfer, apoi rulați din nou ultimele două comenzi.

4. Faceți o copie a setărilor SSH și deschideți fișierul principal:

   cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
   nano /etc/ssh/sshd_config

   Adăugați la sfârșitul fișierului blocul de mai jos și salvați:

   Match Group sftponly
       ChrootDirectory /srv/sftp/%u
       ForceCommand internal-sftp -d /site
       AllowTcpForwarding no
       X11Forwarding no

   Blocul trebuie să rămână ultimul din fișier: tot ce urmează după Match se aplică doar grupului sftponly. %u se înlocuiește cu numele utilizatorului, iar -d /site îl deschide pe coleg direct în directorul site-ului.

   • Nu adăugați PasswordAuthentication în bloc: autentificarea cu parolă o controlați din panou.
   • Nu setați PermitRootLogin no și nu modificați fișierul scris de panou în /etc/ssh/sshd_config.d/.

5. Verificați setările:

   sshd -t

   Dacă comanda nu afișează nimic, setările sunt corecte. Abia apoi reîncărcați SSH:

   systemctl reload ssh || systemctl reload sshd

   Dacă sshd -t afișează o eroare, nu reîncărcați SSH: corectați fișierul sau restaurați copia, apoi verificați din nou cu sshd -t.

   cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config

6. Dintr-un terminal nou, verificați că vă conectați în continuare ca root. Apoi rugați colegul să se conecteze cu un client SFTP, de exemplu FileZilla sau WinSCP, cu utilizatorul NUME_UTILIZATOR și cheia lui, sau din terminal:

   sftp NUME_UTILIZATOR@IP_SERVER

   Colegul ajunge în /site și nu vede nimic în afara directorului /srv/sftp/NUME_UTILIZATOR. Dacă încearcă ssh, primește „This service allows sftp connections only.” și conexiunea se închide.

Dacă ceva nu merge, citiți ultimele mesaje ale serviciului SSH. Pe Ubuntu și Debian:

journalctl -u ssh -n 50

Pe AlmaLinux și CentOS Stream:

journalctl -u sshd -n 50

Retragerea accesului

Când lucrarea s-a încheiat sau persoana pleacă, retrageți accesul imediat.

Cheia de pe root

1. Pe cardul serverului, apăsați „Adaugă cheie SSH”.
2. În „Chei instalate”, găsiți cheia colegului după comentariu și amprentă și apăsați „Șterge”.
3. Confirmați „Ștergeți cheia SHA256:… de pe acest server?” cu „OK”. Apare „Cheie ștearsă.”
4. Apăsați „Resetează parola” și confirmați „Resetați parola pentru NUME_SERVER? Parola curentă încetează să funcționeze imediat.”: cât a avut acces, colegul ar fi putut schimba parola root (Resetarea parolei root).

Utilizatorul separat

Închideți sesiunile lui deschise:

pkill -KILL -u NUME_UTILIZATOR

Apoi ștergeți utilizatorul împreună cu directorul lui. Ubuntu și Debian:

deluser --remove-home NUME_UTILIZATOR

AlmaLinux și CentOS Stream (și Ubuntu sau Debian, dacă deluser cere pachetul perl):

userdel -r NUME_UTILIZATOR

Utilizatorul doar SFTP

Închideți întâi sesiunile lui cu pkill, ca mai sus. Înainte să ștergeți utilizatorul, demontați directorul site-ului, ștergeți linia lui din /etc/fstab și eliminați directoarele rămase goale:

umount /srv/sftp/NUME_UTILIZATOR/site
nano /etc/fstab
rmdir /srv/sftp/NUME_UTILIZATOR/site /srv/sftp/NUME_UTILIZATOR

Risc Nu folosiți rm -r în /srv/sftp. Cât timp directorul site-ului este montat acolo, comanda ar șterge chiar fișierele site-ului. rmdir șterge doar directoare goale, deci refuză dacă montarea este încă activă.

Verificări după plecare

1. Căutați chei, utilizatori și drepturi de administrare pe care nu le recunoașteți. „Chei instalate” arată doar cheile lui root.

   cat /root/.ssh/authorized_keys
   ls -la /home/*/.ssh/authorized_keys
   ls -la /etc/sudoers.d/
   getent group sudo wheel

2. Schimbați secretele pe care persoana le-a cunoscut: parolele bazelor de date (ștergeți și utilizatorul bazei creat pentru ea), cheile aplicațiilor, de exemplu din .env sau wp-config.php, parolele SMTP și cheile serviciilor externe.

3. Verificați autentificările recente:

   last -n 20

   Pe Ubuntu și Debian:

   journalctl -u ssh --since "30 days ago" | grep Accepted

   Pe AlmaLinux și CentOS Stream:

   journalctl -u sshd --since "30 days ago" | grep Accepted

   Liniile Accepted arată utilizatorul, adresa IP și metoda de autentificare. Dacă last lipsește, folosiți doar journalctl.

Dacă bănuiți că accesul a fost folosit abuziv, urmați Serverul a fost spart sau este atacat: ce faceți.

Întrebări frecvente

Poate colegul să vadă serverul în panoul lui? Nu. Un server comandat pe blackbox.md apare doar în contul care l-a comandat și nu se poate partaja în panou. Doar serverele unei companii administrate de BLACKBOX se pot partaja, la cerere, prin suport (Cum contactați suportul BLACKBOX).

Freelancerul îmi cere parola root sau datele contului. Ce fac? Nu le dați. Adăugați-i cheia publică pentru root sau creați-i un utilizator separat. Dacă le-ați dat deja, apăsați „Resetează parola” pe cardul serverului și schimbați parola contului, ceea ce oprește și token-urile API create înainte (Recomandări de securitate pentru contul dvs.). Apoi faceți verificările din secțiunea „Verificări după plecare”.

Cum știu a cui este o cheie din „Chei instalate”? Lista arată începutul amprentei, tipul și comentariul cheii. Rugați colegul să-și pună numele în comentariu când generează cheia și comparați amprenta cu cea trimisă de el: comentariul îl poate scrie oricine, amprenta nu se poate falsifica.

Îi pot da colegului un token API pentru asistentul AI? Nu o faceți. Token-ul acționează în numele dvs., ca titular al contului: cu servers:exec rulează comenzi ca root pe toate serverele dvs., iar cu orders:write plasează comenzi și plătește din sold. Colegul lucrează cu propriul acces SSH.

Colegul are nevoie de cont pe blackbox.md? Nu. Pentru SSH sau SFTP îi ajung cheia lui și accesul pe care i-l dați pe server. Un cont propriu nu îi arată serverele dvs.