Aceste două observații pot coexista într-un singur jurnal SSH:

Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.

Prima privește un ascultător SOCKS dinamic. A doua privește un dispozitiv de rețea de tunel. Sunt cereri de redirecționare diferite.

OpenSSH folosește -D pentru redirecționarea dinamică la nivel de aplicație și -w pentru dispozitivele de tunel. O setare Tunnel poate solicita și aceasta din urmă prin configurație. Neobținerea privilegiilor sau a permisiunii serverului pentru un dispozitiv TUN nu dovedește prin ea însăși că ascultătorul SOCKS anterior nu a fost niciodată creat.

Citește ce a reușit înainte de eroare: autentificarea SSH, crearea ascultătorului și orice cerere ulterioară de canal de destinație. Un port SOCKS în ascultare are încă nevoie de un client compatibil și de o destinație accesibilă și permisă. Este o dovadă despre o singură etapă.

Dacă sarcina vizată este doar redirecționarea SOCKS, verifică de ce a fost solicitat deloc un dispozitiv de tunel. O configurație restrânsă poate dezactiva acea cerere irelevantă:

ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]

Păstrează verificările obișnuite ale cheii de gazdă și ale contului SSH. Nu există niciun motiv să acorzi privilegii de dispozitiv de rețea doar pentru a înăbuși o eroare pentru o funcție de care ruta SOCKS nu are nevoie.

Articole similare