O reenvío SSH SOCKS é independente dos erros do dispositivo TUN
Recoñece un receptor SOCKS establecido aínda que a mesma sesión SSH non logre despois crear un dispositivo TUN á parte.
Estas dúas observacións poden convivir nun mesmo rexistro SSH:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.A primeira refírese a un receptor SOCKS dinámico. A segunda refírese a un dispositivo de rede de túnel. Son solicitudes de reenvío distintas.
OpenSSH usa -D para o reenvío dinámico a nivel de aplicación e -w para os dispositivos de túnel. Un axuste Tunnel tamén pode solicitar este último mediante a configuración. Non obter os privilexios ou o permiso do servidor para un dispositivo TUN non demostra por si mesmo que o receptor SOCKS anterior nunca se crease.
Le o que tivo éxito antes do erro: a autenticación SSH, a creación do receptor e calquera solicitude posterior de canle de destino. Un porto SOCKS á escoita segue necesitando un cliente compatible e un destino accesible e permitido. É evidencia sobre unha etapa.
Se a tarefa prevista é só o reenvío SOCKS, examina por que se solicitou un dispositivo de túnel. Unha configuración restrinxida pode desactivar esa solicitude non relacionada:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]Mantén as comprobacións habituais de clave de host e de conta SSH. Non hai motivo para conceder privilexios de dispositivo de rede só por silenciar un erro dunha función que a ruta SOCKS non necesita.