Puncte:1

Cum se restricționează un utilizator la rbash atunci când se conectează prin SSH

drapel us

Aș dori să restricționez unii utilizatori de pe serverul meu să poată executa doar anumite comenzi. Pentru a face acest lucru, cea mai comună abordare pe care am putut-o găsi este să folosesc rbash.

Deși pot găsi multe site-uri web care vorbesc despre rbash, am probleme în a găsi informații despre cum să-l folosesc corect. Cea mai comună abordare pe care am putut-o găsi a fost să creez un link simbolic din /bin/rbash la /bin/bash, setați shell-ul de conectare pentru utilizatori restricționați la /bin/rbash și apoi setați o personalizare CALE în ~/.bash_profile în directorul principal al utilizatorului.

Cu toate acestea, am fost destul de șocat să aflu că, cu această configurare, utilizatorii pot încă copia fișiere pe server folosind scp și pot chiar să deschidă un shell nerestricționat folosind ssh utilizator@gazdă -t bash! Ceea ce pare să se întâmple este că serverul SSH transmite comanda shell-ului de conectare de pe server folosind -c, asa de ssh utilizator@gazdă -t bash determină rularea serverului /bin/rbash -c bash, care funcționează pentru că .bash_profile nu este încă executat pentru a restricționa calea. scp în mod similar, determină rularea serverului /bin/rbash -c scp.

Acum am dat peste ForceCommand directiva sshd. Această directivă determină, practic, întotdeauna ca comanda configurată să fie transmisă ca -c la shell-ul de conectare, ignorând orice comandă specificată de client. Astfel, dacă ForceCommand este setat sa rbash, care va executa întotdeauna comanda /bin/rbash -c rbash pe server, indiferent dacă clientul a fost apelat cu -t bash sau ca scp sau orice altceva. Din pacate, /bin/rbash -c rbash cauzează .bash_profile sa nu fie executat, asa ca ajungem cu un shell restrictionat dar normal CALE, așa că putem doar să sunăm bash acolo pentru a scăpa de ea.

Ce aș dori să obțin:

  • Nu ar trebui să existe nicio modalitate de a evita shell-ul restricționat pentru utilizatorii care se conectează prin SSH
  • În mod ideal, ar fi încă posibil să executați comenzi care sunt permise în shell-ul restricționat prin utilizarea ssh utilizator@server comanda_permisă
  • Configurația nu ar trebui să fie doar SSH, astfel încât utilizatorii care se conectează, de exemplu, pe TTY ar trebui să fie, de asemenea, restricționați.
Puncte:0
drapel us

După ce am experimentat o vreme cu asta, mi se pare că rădăcina problemei este că securitatea rbash depinde de CALE fiind setat, dar în majoritatea configurațiilor CALE este setat după SSH își specifică comenzile personalizate, în timp ce trebuie specificat inainte de.

Ca o soluție, mai degrabă decât specificarea /bin/rbash (legatură simbolică către /bin/bash ca shell de conectare), am creat un script shell /usr/local/bin/rbash și a folosit-o ca shell de conectare. Scriptul shell are următorul conținut:

#!/bin/bash -l
export PATH=/usr/local/rbin
exec /bin/bash -r „$@”

Am experimentat și cu SetEnv directiva sshd și am încercat să setați CALE Acolo. Cu toate acestea, am găsit această soluție mai puțin practică, deoarece setează configurația doar pentru SSH și, de asemenea, a provocat o mulțime de erori în timpul rulării /etc/profile, deoarece comenzile folosite acolo nu au putut fi găsite. De asemenea, pare să existe riscul ca unele alte directive sshd să permită clientului să suprascrie din nou anumite variabile de mediu.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.