Permiteți utilizatorului să configureze un tunel SSH, dar nimic altceva

Aș dori pentru a permite unui utilizator să creeze un tunel SSH la o mașină special pe un port (să zicem, 5000), dar vreau să restricționeze acest utilizator cât mai mult posibil. (Autentificarea va fi cu pereche cheie publică/privată).

Știu că trebuie să editez fișierul ~/.ssh/authorized_keys relevant, dar nu știu exact ce conținut trebuie introdus acolo (altul decât cheia publică).

0
fr hi bn

10 răspunsuri

Vedeți această postare la autentificarea cheilor publice .

Cele două lucruri principale de care trebuie să vă amintiți sunt:

  1. Make sure you chmod 700 ~/.ssh
  2. Append the public key block to authorized-keys
0
adăugat

Veți genera o cheie pe mașina utilizatorilor prin intermediul oricărui client ssh pe care îl utilizează. pUTTY de exemplu are un utilitar pentru a face acest lucru exact. Aceasta va genera atât o cheie privată, cât și o cheie publică.

Conținutul fișierului cheie cheie generat va fi plasat în fișierul authorized_keys.

Apoi trebuie să vă asigurați că clientul ssh este configurat să utilizeze cheia privată care a generat cheia publică. Este destul de drept înainte, dar ușor diferit în funcție de clientul utilizat.

0
adăugat

Probabil doriți să setați shell-ul utilizatorului pentru a restricționat shell . Dezactivați variabila PATH în fișierele ~/.bashrc sau ~/.bash_profile ale utilizatorului și nu vor putea executa comenzi. Mai târziu, dacă decideți că doriți să permiteți utilizatorilor să execute un set limitat de comenzi, de exemplu less sau tail , atunci puteți copia permisul comenzi către un director separat (cum ar fi /home/commands restrictive ) și actualizarea PATH pentru a indica acel director.

0
adăugat
Da, da, presupunand ca user @ host are ca shell. Consultați Shell-ul restricționat
adăugat autor Jason Day, sursa
Dar acest lucru nu împiedică utilizatorul să specifice o comandă diferită pe linia de comandă ssh, cum ar fi ssh use @ host "/ bin/bash" , nu?
adăugat autor Fritz, sursa
Bine, am încercat și ai dreptate. Întrucât comanda specificată este executată de shell-ul de conectare, executarea /bin/bash eșuează deoarece conține graifări.
adăugat autor Fritz, sursa
Deși ar trebui spus că permiterea less este probabil o idee proastă, pentru că de acolo puteți să scăpați într-o coajă nerestricționată cu !/Bin/bash . Consultați pen- test.sans.org/blog/2012/06/06/… pentru alte exemple. Deci, permițând comenzilor individuale să se facă foarte, foarte atent, dacă este deloc.
adăugat autor Fritz, sursa

Soluția mea este de a furniza utilizatorului fără o coajă interactivă un tunel, care poate seta /etc/passwd /usr/bin/tunnel_shell .

Doar creați fișierul executabil /usr/bin/tunnel_shell cu o buclă infinită .

#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0

Fully explained here: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

0
adăugat
mulțumesc pentru sugestie, am adăugat capturarea unor semnale de întrerupere
adăugat autor DanFromGermany, sursa
@BigPapoo: Ați testat-o? Nu pot să văd de unde ar scăpa. Dacă sunteți într-o coajă și executați tunnel_shell , veți avea shell ->/bin/bash tunnel_shell astfel încât să puteți evada înapoi în coajă. dacă ați setat tunnel_shell ca shell-ul utilizatorului, veți avea doar /bin/bash tunnel_shell , cat de departe pot vedea. Am testat-o ​​și nu am putut scăpa cu ctrl-z. Dacă ați încercat și ați putea scăpa, ați putea posta configurarea? De asemenea, dacă știți despre orice documentație care spune că ar trebui să funcționeze a
adăugat autor Aleksi Torhamo, sursa
Folosesc doar/bin/pisica pentru o "coajă". Pare să funcționeze bine. Nu sunteți conștienți de niciun fel de exploatări împotriva pisicilor și chiar dacă ați găsit un model de intrare care reușește să-l prăbușească, sesiunea dvs. ssh ar înceta.
adăugat autor flabdablet, sursa
CTRL + Z va scapa de script oferindu-vă acces deplin la bash ... Încercați să adăugați "capcana" 20 "(fără citate) la începutul scriptului
adăugat autor Big Papoo, sursa

Pe Ubuntu 11.10, am constatat că am putea bloca comenzile ssh, trimis cu și fără -T și blocând copierea scp, permițând în același timp parcurgerea porturilor.

Mai exact am un server redis pe "somehost" legat de localhost: 6379 pe care doresc să-l împărtășesc în siguranță prin tunelurile ssh către alte host-uri care au un keyfile și care vor ssh in cu:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 [email protected]

Acest lucru va face ca serverul redis, portul "localhost" 6379 pe "somehost" să apară local pe gazda care execută comanda ssh, remapată la portul "localhost" 16379.

Pe telecomanda "somehost" Iată ce am folosit pentru authorized_keys:

cat .ssh/authorized_keys   (portions redacted)

no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here [email protected]

No-pty trips până cele mai multe încercări ssh care doresc să deschidă un terminal.

Permisul de permis explică ce porturi sunt permise să fie redirecționate, în acest caz portul 6379 portul redis-server pe care doream să-l înaintez.

Comanda = "/ bin/echo do-not-send-commands" repeta comenzile "do-not-send" daca cineva sau ceva nu reuseste sa trimita comenzi catre gazda prin ssh -T sau altfel.

De la un om recent om sshd , autorizat_keys/comanda este descris după cum urmează:

comanda = "comanda"                Specifică faptul că comanda este executată ori de câte ori această cheie este utilizată                pentru autentificare. Comanda furnizată de utilizator (dacă există) este                ignorate.

Încercările de a folosi copierea securizată a fișierelor scp vor eșua, de asemenea, cu un ecou al "do-not-send-commands". Am constatat că sftp nu reușește și cu această configurație.

Cred că sugestia de coajă limitată, făcută în unele răspunsuri anterioare, este, de asemenea, o idee bună. De asemenea, aș fi de acord că tot ceea ce este detaliat aici ar putea fi determinat de la citirea "om sshd" și căutarea în acesta pentru "authorized_keys"

0
adăugat
Răspuns foarte util. Aș adăuga doar că /sbin/nologin pentru un utilizator pare să funcționeze bine cu -N și port forwarding (dacă toate persoanele care se conectează la acel cont trebuie tratate la fel cale).
adăugat autor Marcin Zajączkowski, sursa
În timp ce no-pty nu permite deschiderea sesiunii interactive, nu face nimic pentru a împiedica executarea comenzii, astfel încât utilizatorul poate edita fișierul authorized_keys dacă are acces cu ceva > serverul ssh "sed-i -es/no-pty//~/.ssh/authorized_keys" .
adăugat autor synapse, sursa
numai despre no-pty
adăugat autor synapse, sursa
Comanda @synapse = "/ bin/echo do-not-send-commands", de asemenea, enumerate mai sus, este destinată blocării comenzilor. și să furnizeze un mesaj. Ați intenționat exemplul dvs. să învingeți întreaga setare de mai sus sau comentați numai pe no-pty?
adăugat autor Paul, sursa
Se menționează faptul că administratorii nu sunt obligați să acorde utilizatorilor dreptul de proprietate asupra unui fișier authorized_keys sau care conține un director și nici că există într-un director de domiciliu al utilizatorilor (presupunând că serverul ssh este configurat corespunzător pentru locația sa)
adăugat autor Dan Farrell, sursa
@AndrewWolfe de obicei, ~ user/.ssh/authorized_keys ar fi proprietatea user , iar user ar gestiona cheile autorizate utilizate pentru a accesa contul . SSH este preocupat de permisiuni și poate impune așteptări în ~/.ssh/ și conținutul său. Am făcut o root sudo chown: .ssh/authorized_keys și mi se pare că m-au oprit de la conectare, dar știu din experiența trecută că utilizatorul nu trebuie să dețină acel fișier - root îl puteți gestiona dacă preferați.
adăugat autor Dan Farrell, sursa
?? @DanFarrell ar fi .ssh/authorized_keys deținute de rădăcină, de roată sau de cine?
adăugat autor Andrew Wolfe, sursa

Am posibilitatea de a configura fișierul authorized_keys cu cheia publică pentru a vă conecta   Ceea ce nu sunt sigur sunt informațiile suplimentare de care am nevoie   să restricționeze ceea ce este permis să facă acest cont. De exemplu, știu că pot   puneți comenzi cum ar fi:

  no-pty, fără port-expediere, no-X11-expediere, fără agent de expediere
 

Ați dori o linie în fișierul dvs. authorized_keys care arată astfel.

permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache 
0
adăugat

Dacă doriți să permiteți accesul numai pentru o anumită comandă - cum ar fi svn - puteți specifica și acea comandă în fișierul chei autorizate:

command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]

From http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

0
adăugat

Pe lângă opțiunea authorized_keys, cum ar fi redirecționarea fără X11, există exact una pentru care cereți: permitopen = "host: port". Prin utilizarea acestei opțiuni, utilizatorul poate seta un tunel numai pentru gazda și portul specificat.

Pentru detalii despre formatul de fișier AUTHORIZED_KEYS, consultați omul sshd.

0
adăugat
@JohnHart: no-pty nu restricționează accesul la shell, fie veți ajunge la shell, nu vă va afișa promptul; Puteți da în continuare comenzi și puteți vedea ieșirea foarte bine. Aveți nevoie de opțiunea command = "..." dacă doriți să restricționați accesul shell din .ssh/authorized_keys .
adăugat autor Aleksi Torhamo, sursa
Restricționarea redirecționării porturilor cu permis de deschidere blochează de asemenea tipul de redirecționare a dispozitivelor de tunel solicitat de ssh -w?
adăugat autor flabdablet, sursa
Va trebui să specificați și "no-pty" ca parte a setului de opțiuni. Dacă folosiți doar "permitopen", atunci veți restricționa tunelurile la gazda/portul dat ... dar veți permite în continuare shell-uri interactive.
adăugat autor John Hart, sursa

Am făcut un program C care arată astfel:

#include 
#include 
#include 
#include 
void sig_handler(int signo)
{
    if (signo == SIGHUP)
        exit(0);
}

int main()
{
    signal(SIGINT, &sig_handler);
    signal(SIGTSTP, &sig_handler);

    printf("OK\n");
    while(1)
        sleep(1);
    exit(0);
}

Am setat shell-ul utilizatorului restricționat la acest program.

Nu cred că utilizatorul restricționat poate executa orice, chiar dacă face comanda ssh server , deoarece comenzile sunt executate folosind shell-ul, iar această shell nu execută nimic.

0
adăugat

Here you have a nice post that I found useful: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

Ideea este: (cu numele de utilizator restricționat nou ca "sshtunnel")

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel

Rețineți că folosim rbash (restrict-bash) pentru a restrânge ce poate face utilizatorul: utilizatorul nu poate să cd (schimba directorul) și nu poate seta vreo variabilă de mediu.

Apoi, editează variabila PATH env a utilizatorului în /home/sshtunnel/.profile pentru nimic - un truc care va face ca bash să nu găsească comenzi de executat:

PATH=""

În cele din urmă, nu permitem utilizatorului să editeze niciun fișier prin setarea următoarelor permisiuni:

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
0
adăugat