“Canal 3: falha na abertura: proibido administrativamente: falha na abertura” ao criar uma sessão VNC em um túnel SSH

Ao criar uma conexão VNC via conexão SSH encapsulada, recebo um erro:

channel 3: open failed: administratively prohibited: open failed

Descobri que isso acontece apenas quando não estou conectado no host localmente como usernameno host ao qual estou tentando conectar-me usando uma conexão VNC em túnel. Túnel SSH:

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

Conexão VNC:

vncviewer localhost:1

Tentei ajustar as configurações /etc/ssh/sshd_configusando AllowTunnel yese sem a configuração. (Reiniciei o ssh após cada alteração:) service ssh restartNo entanto, o erro desaparece se eu tiver uma sessão local em execução no host remoto (ou seja, eu estiver conectado como usernamelocalmente.) Alguém mais está vendo esse comportamento? Parece que eu deveria poder iniciar um VNC remotamente e acessá-lo sem precisar fazer login localmente também.

— Mike Swartz
fonte

Mike, verifique o tour para ver como funciona este site e, se minha resposta resolveu seu problema, aceite-o.

— Jakuje

Respostas:

A opção que você está procurando não é AllowTunnel(é para VPN e encaminhamento de nível 3 usando tundispositivos). Você está procurando AllowTcpForwarding, que lida com o encaminhamento de porta local e remota do tráfego TCP no ssh.

Veja quais valores estão no seu servidor e altere-o para yes:

AllowTcpForwarding yes

— Jakuje
fonte

Obrigado pela sua resposta rápida. Isso parece ter corrigido o meu problema. Eu já tinha visto os outros com o mesmo problema e uma sugestão foi AllowTunnel yesem sshd_config, mas que não funcionou para mim.

— Mike Swartz

Provavelmente é uma lenda urbana, pois também a outra resposta veio aqui. Não faço ideia de onde veio e é tão fácil abrir a página de manual e verificar o significado. Se funcionar para você, tenha um segundo para verificar a resposta como solução para ajudar outras pessoas.

— Jakuje 6/12/15

Por que o voto negativo?

— Jakuje 7/11

AllowTcpForwarding Especifica se o encaminhamento de TCP é permitido. As opções disponíveis são "yes" ou "all" para permitir o encaminhamento de TCP, "no" para impedir todo o encaminhamento de TCP, "local" para permitir somente o encaminhamento local (da perspectiva do ssh (1)) ou "remoto" para permitir o encaminhamento remoto encaminhamento apenas. O padrão é "sim".

— Bart Polot

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

— YSC

Eu tive uma causa de resolução de nomes para esse erro. Meus / etc / hosts tinham um endereço IP incorreto para o nome do servidor (não para localhost), assim:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Mas o IP do servidor configurado (e o nome DNS resolvido com os comandos host / dig) era 192.168.2.47. Um erro de digitação simples causado por uma reconfiguração de IP anterior. Depois de corrigir o / etc / hosts, a conexão do túnel funcionou perfeitamente:

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

É estranho que o IP real tenha causado a falha quando eu estava usando o IP literal do host local para o túnel. Distro: Ubuntu 16.04 LTS.

— Fjor
fonte