Cum să restricționezi utilizatorii SSH la anumite directoare pe Ubuntu 24.04 (Ghid SFTP Chroot)

Acordarea unui contractor acces pentru a încărca câteva fișiere nu ar trebui să ofere automat acelei persoane o sesiune terminal cu o vedere asupra întregului server. Pe Ubuntu 24.04 LTS, OpenSSH poate limita un cont de transfer de fișiere la un director ales folosind o ChrootDirectoryregulă și serverul încorporat internal-sftp. Distincția importantă este că aceasta este o restricție exclusivă pentru SFTP , nu o modalitate simplă de a oferi un shell Bash complet funcțional, dar închis.

Acest ghid explică ce protejează de fapt setările, apoi prezintă o configurare reversibilă, în opt etape, pentru mai multe conturi, fiecare cu propriul director. Comenzile utilizează un cont exemplu numit contractorși o gazdă exemplu numită server.example.com; înlocuiți-le cu propriile valori. Acestea sunt exemple de configurare, nu rezultate revendicate dintr-un test live al serverului.

De ce tip de restricție ai nevoie, de fapt?

Trei controale sunt adesea confundate. Permisiunile Linux decid ce fișiere poate citi sau modifica un cont; schimbarea directorului principal al contului stabilește o locație inițială; un chroot modifică rădăcina sistemului de fișiere prezentată unui proces. Nu sunt interschimbabile.

Concepție greșită: setarea /home/contractordirectorului principal limitează utilizatorul acolo. Nu este așa. Un utilizator shell normal se poate muta în orice director accesibil în altă parte a sistemului de fișiere. Dacă schimbul de fișiere este cerința reală, alegeți ruta SFTP-only de mai jos, în loc să încercați să ascundeți directoarele cu promptul shell.

Documentele OpenSSH ChrootDirectory, Match, și ForceCommandîn manualul oficial sshd_config pentru Ubuntu 24.04 .

Configurați o închisoare de directoare exclusiv SFTP în opt etape

Înainte de a modifica SSH de la distanță, mențineți deschisă sesiunea de administrator existentă și asigurați-vă că aveți acces la consolă sau la recuperare. Folosiți un cont separat, neprivilegiat, pentru transferuri; nu includeți contul de administrator în grupul restricționat.

1. Verificați OpenSSH și mențineți o sesiune de recuperare

Pe server, instalați OpenSSH dacă este necesar, verificați serviciul și salvați configurația principală. Documentația oficială a serverului Ubuntu oferă suport pentru aceste servicii și căi de configurare.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Dacă puteți administra mașina doar prin SSH, nu închideți sesiunea curentă în timp ce editați sau testați. Consultați ghidul de configurare a serverului Ubuntu OpenSSH înainte de a modifica daemonul.

2. Creați un utilizator dedicat și un grup de acces SFTP

Un grup este util atunci când vă așteptați la mai mult de un cont restricționat. Acest exemplu oferă fiecărui membru un jail separat folosind %utoken-ul, pe care OpenSSH îl extinde la numele de utilizator care se conectează. /uploadCalea principală este destinată să existe în interiorul viitorului chroot, așa că nu creați un /uploaddirector la nivel de gazdă.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

Fluxul adduservă poate solicita să atribuiți o parolă. În instalările care dezactivează autentificarea prin parolă SSH, creați și autorizați o cheie publică; nu activați la nivel global autentificările prin parolă doar pentru a urma un exemplu. Shell-ul nologineste o altă măsură de siguranță, dar comanda impusă internal-sftpeste cea care face ca această configurație să fie doar pentru transfer. Testați combinația pe propria stivă de autentificare.

3. Construiți un director chroot deținut de root

Aici greșesc multe ghiduri. OpenSSH necesită ca fiecare componentă a căii chroot să fie deținută de root și să nu poată fi scrisă de alți utilizatori sau grupuri. Nu faceți niciodată ca jail root-ul în sine să poată fi scris de contul SFTP.

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

/Verificați și componentele existente /srvși ; comenzile de mai sus nu repară automat permisiunile părinte nesigure. Dacă vreo componentă este permisă scrierea în grup sau este deținută de utilizator, corectați proprietatea și modul acesteia numai după ce verificați dacă alte aplicații se bazează pe ea.

4. Adăugați un subdirector în care se poate scrie în interiorul jail-ului

Contul poate scrie într-un director copil fără a avea permisiunea de a modifica directorul rădăcină chroot. Creați /srv/sftp/contractor/uploadpentru fișierele propriu-zise ale contului; din interiorul SFTP, acesta va apărea ca /upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

Proprietarul așteptat diferă în mod deliberat: root:rootpentru rădăcina jail și contractor:contractorpentru folderul de încărcare cu acces inscriptibil. Evitați chmod 777, care ar introduce o expunere inutilă și ar fi respins dacă ar fi aplicat la rădăcina jail.

5. Adăugați o regulă de potrivire la sshd_config

Deschideți /etc/ssh/sshd_configși adăugați următorul bloc la sfârșit, după orice directive și Matchblocuri existente. Folosiți un editor de text, cum ar fi sudoeditsau sudo nano. Verificați mai întâi regulile existente Match: dacă mai multe blocuri potrivite atribuie același cuvânt cheie, OpenSSH folosește prima instanță aplicabilă. De asemenea, Ubuntu procesează fișiere dintr- /etc/ssh/sshd_config.d/o listă timpurie Include; regulile de acolo pot afecta precedența.

Match Group sftpclients
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    PermitTTY no
    DisableForwarding yes

Match Groupvizează membrii sftpclients. ChrootDirectoryplasează fiecare utilizator sub /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadrulează un serviciu SFTP în proces și pornește în interiorul directorului în care se poate scrie. PermitTTY noprevine alocarea terminalului, în timp ce DisableForwarding yesdezactivează funcțiile de redirecționare SSH pentru conexiunile corespondente.

Păstrați directiva globală Subsystem sftpdeja furnizată de Ubuntu, cu excepția cazului în care aveți un motiv separat pentru a o modifica; comanda SFTP internă forțată nu necesită înlocuirea acelei linii globale. Nu adăugați o linie globală suplimentară Match Alldoar pentru a încheia un bloc fără a înțelege ce ar afecta.

6. Verificați sintaxa și setările efective înainte de reîncărcare

Succesul analizei nu dovedește că permisiunile pentru jail sunt corecte și nici că respectivul cont corespunde politicii. Efectuați ambele verificări în mod explicit.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

Configurația efectivă ar trebui să identifice calea chroot dorită, comanda SFTP forțată, alocarea TTY dezactivată și restricțiile de redirecționare. Adresa exemplu 192.0.2.10este doar pentru documentație; dacă aveți Matchreguli dependente de adresă, înlocuiți-o cu adresa sursă reală a clientului. Formularul -T -Ceste documentat în manualul Ubuntu 24.04 sshd .

Dacă validarea eșuează, remediați configurația înainte de a reîncărca SSH. Dacă valorile efective sunt neașteptate, verificați fragmentele incluse și ordinea blocurilor condiționale existente, nu doar ultimele linii editate.

7. Reîncărcați SSH-ul și păstrați-vă accesul de administrator

După verificările reușite, reîncărcați serviciul SSH astfel încât noile conexiuni să utilizeze politica editată. Mențineți conexiunea curentă de administrator activă în timp ce deschideți un al doilea terminal pentru a confirma că accesul normal de administrator funcționează în continuare.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

O repornire completă poate aplica și modificări, dar o reîncărcare este preferabilă atunci când este acceptată și doriți să evitați întreruperi inutile. Ieșirea comenzii de service și mesajele din jurnal variază în funcție de gazdă, așadar inspectați rezultatul real, mai degrabă decât presupuneți că o revenire cu succes la prompt garantează accesul.

8. Testarea transferurilor permise și a accesului blocat la shell

De pe un alt computer, conectați-vă ca utilizator restricționat. Folosiți numele de gazdă real al serverului și un fișier de test adecvat. Primul director SFTP ar trebui să fie /upload, iar rădăcina chroot ar trebui să apară ca , /în loc de calea gazdei /srv/sftp/contractor.

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

Încărcarea unui fișier de test inofensiv ar trebui să fie permisă în /upload. Accesarea directorului real al gazdei /etcnu ar trebui să fie posibilă: chroot-ul definește o rădăcină diferită și /etcar fi accesibil numai dacă ați crea sau expune în mod deliberat un astfel de director în interiorul jail-ului. Textul exact al erorii clientului nu este important.

ssh contractor@server.example.com

O interfață SSH interactivă obișnuită nu trebuie să se deschidă pentru acest cont. În schimb, conexiunea se poate închide sau afișa un mesaj legat de protocol; nu vă bazați pe o frază exactă. Dacă se deschide o interfață, tratați configurația ca fiind nesigură și verificați din nou apartenența la grup, Matchprecedența și sshd -T -Cieșirea efectivă înainte de a utiliza contul.

Ce se întâmplă dacă folosești chei publice SSH?

Autentificarea cu cheie publică funcționează cu o jail SFTP, dar plasarea home-ului la nivel de gazdă al unui utilizator la /uploadînseamnă că este posibil ca calea implicită ~/.ssh/authorized_keyssă nu existe în afara jail-ului. O alternativă practică este să permiteți SSH să citească un fișier cu cheie controlată de root înainte de a porni chroot-ul. Adăugați acest lucru în interiorul aceluiași Match Group sftpclientsbloc dacă alegeți stocarea centralizată a cheilor:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Apoi creați /etc/ssh/authorized_keys/contractorun fișier care conține cheia publică autorizată a contractorului, cu proprietatea root și fără permisiuni de scriere de grup sau globală. De exemplu, după copierea în siguranță a unui fișier cu cheie publică verificat, numit contractor.pubîntr-un director administrativ de testare:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

Nu copiați o cheie privată pe server. Setarea căii pentru cheie, setările implicite de autentificare și verificările contului depind de politica SSH existentă; verificați accesul la cheia publică înainte de a dezactiva o metodă de autentificare deja funcțională.

Eșecuri comune și ce înseamnă acestea

Verificați jurnalele cu sudo journalctl -u ssh -n 80 --no-pager. Eroarea exactă depinde de setările PAM, configurația SSH, accesul la sistemul de fișiere și metoda de autentificare. OpenSSH 9.0 și versiunile mai noi utilizează SFTP pentru scptransferurile standard în mod implicit, în timp ce modul legacy necesită un shell, așa cum se explică în manualul Ubuntu 24.04 scp .

Poți restricționa un shell SSH interactiv la un singur folder?

Nu cu o schimbare de director home sau cu exemplul SFTP-only de mai sus. OpenSSH-urile ChrootDirectorypot fi folosite și pentru sesiuni shell, dar jail-ul trebuie să includă un shell utilizabil, bibliotecile sale partajate și nodurile de dispozitiv necesare, precum și orice dependențe de comenzi. Construirea acestui mediu în siguranță necesită mai mult decât setarea unei singure linii în sshd_config. Este ușor să creezi o configurație fragilă sau înșelătoare, mai ales atunci când sunt implicate comenzi sau montări arbitrare în shell.

Dacă un utilizator are nevoie cu adevărat de comenzi interactive, trebuie mai întâi să specificați exact ce comenzi și fișiere are nevoie. Pentru un set mic de comenzi, utilizați comenzi la distanță cu scop restrâns sau un endpoint dedicat aplicației. Pentru medii independente mai largi, luați în considerare un container sau o mașină virtuală cu montări explicite ale sistemului de fișiere, controale de privilegii și restricții de rețea. Un chroot în sine nu înlocuiește izolarea completă a sistemului și nici chroot, nici permisiunile de fișiere Unix nu protejează împotriva unui utilizator privilegiat care poate modifica sistemul subiacent.

Listă de verificare a securității înainte de acordarea accesului

• Contul de transfer nu este de administrator și aparține doar grupurilor necesare.
• Fiecare componentă care duce la jail este deținută de root și nu poate fi scrisă de grup sau de către întreaga lume.
• Locația de încărcare cu care se poate scrie este în interiorul jail-ului, nu în rădăcina jail-ului în sine.
• Utilizatorul vizat se potrivește cu ChrootDirectory, ForceCommand internal-sftpși a dezactivat redirecționarea în configurația efectivă.
• O încărcare SFTP reală reușește, o încercare de a accesa fișierele exclusiv gazdă eșuează, iar accesul normal la shell-ul SSH este blocat.
• Copierea de rezervă, păstrarea, cotele, monitorizarea și revocarea conturilor sunt gestionate separat; o arhivă de directoare nu implementează automat aceste politici.

Pentru mai multe detalii tehnice, consultați referința de configurare OpenSSH Ubuntu 24.04 și manualul serverului SFTP Ubuntu . Aceste instrucțiuni vizează Ubuntu 24.04 LTS; versiunile pachetelor și fragmentele SSH existente pot modifica comportamentul efectiv, așadar autoritatea finală o reprezintă configurația și testele de conexiune efective pe propria gazdă.