"Canal 3: error de apertura: prohibido administrativamente: error de apertura" al crear una sesión VNC en un túnel SSH

Al crear una conexión VNC a través de una conexión SSH tunelizada, aparece un error:

channel 3: open failed: administratively prohibited: open failed

He descubierto que esto sucede solo cuando no estoy conectado al host localmente como usernameen el host al que estoy tratando de conectarme usando una conexión VNC tunelizada. Túnel SSH:

ssh -p 6000 -L 5901:127.0.0.1:5901 username@192.168.0.2

Conexión VNC:

vncviewer localhost:1

Intenté ajustar la configuración /etc/ssh/sshd_configusando AllowTunnel yesy sin la configuración. (Reinicié ssh después de cada cambio:) service ssh restartSin embargo, el error desaparece si tengo una sesión local ejecutándose en el host remoto (es decir, estoy conectado como usernamelocal). ¿Alguien más está viendo este comportamiento? Parece que debería poder iniciar un VNC de forma remota y acceder a él sin tener que iniciar sesión localmente también.

— Mike Swartz
fuente

Mike, comprueba el recorrido para ver cómo funciona este sitio y si mi respuesta resolvió tu problema, acéptalo.

— Jakuje

Respuestas:

La opción que está buscando no es AllowTunnel(es para VPN y reenvío de nivel 3 usando tundispositivos). Está buscando AllowTcpForwarding, que maneja el reenvío de puertos TCP locales y remotos en el tráfico ssh.

Observe qué valores hay en su servidor y cámbielo a yes:

AllowTcpForwarding yes

— Jakuje
fuente

Gracias por su pronta respuesta. Eso parece haber solucionado mi problema. Había visto a otros con el mismo tema y fue una sugerencia AllowTunnel yesen sshd_config, pero eso no funcionó para mí.

— Mike Swartz

Probablemente sea una leyenda urbana, ya que la otra respuesta vino aquí. No tengo idea de dónde vino y es tan fácil abrir la página del manual y verificar el significado. Si funciona para usted, tenga un segundo para verificar la respuesta como solución para ayudar a otros.

— Jakuje

¿Por qué el voto negativo?

— Jakuje el

AllowTcpForwarding Especifica si se permite el reenvío de TCP. Las opciones disponibles son "sí" o "todos" para permitir el reenvío de TCP, "no" para evitar todo el reenvío de TCP, "local" para permitir el reenvío local (desde la perspectiva de ssh (1)) solamente o "remoto" para permitir el control remoto reenvío solamente. El valor predeterminado es "sí".

— Bart Polot

relacionado (falso): serverfault.com/a/24389/328011

— YSC

Tenía una causa de resolución de nombre para este error. Mi / etc / hosts tenía una dirección IP errónea para el nombre del servidor (no para localhost), así:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Pero la IP configurada del servidor (y el nombre DNS resuelto con los comandos host / dig) fue 192.168.2.47. Un error tipográfico simple causado por una reconfiguración de IP anterior. Después de arreglar / etc / hosts, la conexión del túnel funcionó a la perfección:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

Es extraño que la IP real haya causado la falla cuando estaba usando la IP literal localhost para el túnel. Distribución: Ubuntu 16.04 LTS.

— Fjor
fuente