Setarea tentantă este AllowTcpForwarding no. Din păcate, aceasta dezactivează și redirecționarea de care are nevoie un proxy SSH SOCKS local. Redirecționarea dinamică nu este o portiță în jurul politicii serverului.

Pentru un cont dedicat, OpenSSH separă mai multe capabilități. Un fragment de politică poate permite redirecționarea locală blocând în același timp sesiunile shell și de subsistem:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

Manualul serverului descrie MaxSessions 0 ca o setare care blochează sesiunile shell, de autentificare și de subsistem, permițând redirecționarea. Integrați-o într-un cont autentificat existent; nu este o configurație completă de securitate SSH.

Doar redirecționare nu înseamnă doar SOCKS

O redirecționare locală fixă și o cerere SOCKS pot solicita în final serverului același tip de conexiune de destinație. Permiterea redirecționării locale nu garantează că un client a folosit o anumită interfață SOCKS. Nu descrieți contul ca impunând utilizarea doar SOCKS.

PermitOpen poate restricționa perechile gazdă și port de destinație când o listă specifică se potrivește cerinței. Nu este o interdicție generală conștientă de rezolvarea numelor pe fiecare rețea privată. Restricții mai largi de adrese pot necesita o politică de rețea de gazdă adecvată.

Setările contului, ale cheii și ale serverului inclus pot restricționa și mai mult redirecționarea. O interdicție generală de redirecționare în altă parte poate elimina o capabilitate pe care acest fragment pare să o permită.

Folosiți procedura obișnuită de administrare a serverului cu o cale de recuperare, apoi evaluați separat capabilitățile permise și interzise. Rezultatul dorit sunt permisiuni explicite de redirecționare, nu o autentificare interactivă lăsată disponibilă din greșeală sau un proxy dezactivat de propria restricție.

Articole similare