El reenvío SSH SOCKS es independiente de los errores del dispositivo TUN
Reconoce un receptor SOCKS establecido aunque la misma sesión SSH no logre después crear un dispositivo TUN aparte.
Estas dos observaciones pueden coexistir en un mismo registro SSH:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.La primera se refiere a un receptor SOCKS dinámico. La segunda se refiere a un dispositivo de red de túnel. Son solicitudes de reenvío distintas.
OpenSSH usa -D para el reenvío dinámico a nivel de aplicación y -w para los dispositivos de túnel. Un ajuste Tunnel también puede solicitar este último mediante la configuración. No obtener los privilegios o el permiso del servidor para un dispositivo TUN no demuestra por sí mismo que el receptor SOCKS anterior nunca se creara.
Lee qué tuvo éxito antes del error: la autenticación SSH, la creación del receptor y cualquier solicitud posterior de canal de destino. Un puerto SOCKS a la escucha sigue necesitando un cliente compatible y un destino accesible y permitido. Es evidencia sobre una etapa.
Si la tarea prevista es solo el reenvío SOCKS, examina por qué se solicitó un dispositivo de túnel. Una configuración acotada puede desactivar esa solicitud no relacionada:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]Mantén las comprobaciones habituales de clave de host y de cuenta SSH. No hay motivo para conceder privilegios de dispositivo de red solo por silenciar un error de una función que la ruta SOCKS no necesita.