Erro de tunelamento SSH: “canal 1: falha na abertura: proibida administrativamente: falha na abertura”

Question

Quando abro este túnel ssh:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

Eu recebo este erro ao tentar acessar o servidor HTTP em execução no host local: 8984:

channel 1: open failed: administratively prohibited: open failed

O que esse erro significa e em qual máquina você pode corrigir o problema?

    

Answer 1

channel 1: open failed: administratively prohibited: open failed

A mensagem acima se refere ao seu servidor SSH rejeitar a solicitação do seu cliente SSH para abrir um canal lateral. Isso normalmente vem de -D , -L ou -w , pois canais separados no fluxo SSH são necessários para transportar os dados encaminhados.

Como você está usando -L (também aplicável a -D ), há duas opções em questão que estão fazendo com que seu servidor SSH rejeite essa solicitação:

• AllowTcpForwarding (como Steve Buzonas mencionou)
• PermitOpen

Essas opções podem ser encontradas em /etc/ssh/sshd_config . Você deve garantir que:

• AllowTCPForwarding não está presente, está comentado ou está definido como yes
• PermitOpen não está presente, está comentado ou está definido como any [1]

Além disso, se você estiver usando uma chave SSH para se conectar, verifique se a entrada correspondente à sua chave SSH em ~/.ssh/authorized_keys não tem no-port-forwarding ou permitopen instruções [2].

Não relevante para o seu comando em particular, mas também relevante para este tópico, é a opção PermitTunnel se você está tentando usar a opção -w.

[1] Sintaxe completa na sshd_config(5) página de manual.

[2] Sintaxe completa na authorized_keys(5) página de manual.

    

Answer 2

Em um caso muito estranho, eu também sofri esse erro ao tentar criar um túnel local. Meu comando era algo assim:

ssh -L 1234:localhost:1234 user@remote

O problema era que, no host remoto, /etc/hosts não tinha entrada para "localhost", então o servidor ssh não sabia como configurar o túnel. Uma mensagem de erro muito hostil para este caso; feliz por finalmente ter descoberto isso.

A lição: certifique-se de que o hostname de destino do seu túnel seja resolvido pelo host remoto, seja via DNS ou /etc/hosts .

    

Answer 3

Pelo menos uma resposta é que a máquina "remota" está inacessível com o ssh por algum motivo. A mensagem de erro é simplesmente absurda.

    

Answer 4

Se o 'remote' não puder ser resolvido no servidor, você receberá esse erro. Substitua por um endereço IP e veja se isso resolve o problema ...

(Basicamente a mesma resposta de Neil - mas eu certamente achei que esse era o problema do meu lado) [eu tinha um alias para o nome da máquina no meu arquivo ~/.ssh/config - e a máquina remota não sabia nada disso ...

    

Answer 5

Esse erro aparece definitivamente quando você usa as opções ssh ControlPath e ControlMaster para compartilhar uma conexão de soquete a ser reutilizada entre várias conexões de cliente (de um cliente para o mesmo usuário @ servidor). Abrindo muitos (o que isso significa, no meu caso ~ 20 conexões) produz esta mensagem. Fechar todas as conexões anteriores me permite abrir mais uma vez, até o limite.

    

Answer 6

"administrativamente proibido" é um sinalizador de mensagem ICMP específico que se resume a "O administrador deseja explicitamente que esta conexão seja bloqueada".

Verifique suas configurações do iptables.

    

Answer 7

Um problema semelhante

Outra possível pista

Eu tive o mesmo problema usando ~/.ssh/authorized_keys com permitopen .

Como eu uso o autossh para criar um túnel, preciso de duas portas:

• um para conexão (10000),
• um para monitoramento (10001).

No lado do cliente

Isso me deu um problema semelhante com a porta de monitoramento:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

Eu recebi essa mensagem (depois de 10 minutos):

channel 2: open failed: administratively prohibited: open failed

No lado remoto

Meu /var/log/auth.log continha:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

No meu ~/.ssh/authorized_keys (lado remoto) eu tive isto:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

Como resolver isso

Eu resolvi isso substituindo localhost instances por 127.0.0.1 :

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

Parece que o SSH não entende que localhost é um atalho para 127.0.0.1 , daí a mensagem em auth.log e a mensagem proibida administrativamente .

O que eu entendo aqui é que administrativamente significa "devido a uma configuração específica no lado do servidor".

    

Answer 8

Isso também acontece quando /etc/sshd_config tem

AllowTcpForwarding no 

definido. Mude para yes para permitir o encaminhamento TCP.

    

Answer 9

Algumas atividades de solução de problemas são necessárias para encontrar uma resposta definitiva:

• verifique se o encaminhamento de porta está ativado na configuração do ssh do usuário,
• permite verbosidade de ssh (-v),
• verifique os logs do ssh no host local e proteja os logs em um remoto,
• testa uma porta remota diferente,
• verifique suas configurações do iptables (como Shadur disse).

Answer 10

Eu recebi esse erro uma vez para colocar o controle remoto no parâmetro -L, também o 0.0.0.0 é redundante, você pode omiti-lo com os mesmos resultados, e eu acho que você deve adicionar o -g para ele funcionar.

Esta é a linha que eu uso para tunelamento: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

    

Answer 11

Eu tive a mesma mensagem enquanto tentava tunelar. Houve um problema com o servidor dns no lado remoto. O problema foi resolvido quando voltou ao trabalho.

    

Answer 12

No meu caso, o problema foi devido a solicitação de um túnel sem acesso ao shell, enquanto o servidor visava forçar uma alteração de senha na minha conta. Devido à falta de um shell, eu não pude ver isso e só recebi o erro

channel 2: open failed: administratively prohibited: open failed  

A configuração do meu túnel foi a seguinte:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

O erro foi exibido ao efetuar login diretamente no servidor (sem -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

Resolvi o problema fazendo login com o acesso ao shell e alterando a senha. Então eu poderia simplesmente usar túneis sem acesso ao shell novamente.

    

Answer 13

No meu caso, tive que substituir localhost por 127.0.0.1 em:

ssh -L 1234:localhost:3389 user@remote

para que funcione.

Eu estava tentando rdesktop -L localhost:1234 seguindo as instruções da Amazon para se conectar ao AWS EC2 via Tunelamento SSH . Eu tentei alterar /etc/ssh/sshd_config (cliente e servidor rodam o Ubuntu 16.04 LTS) pela resposta mais votada. Também verifiquei que localhost está em /etc/hosts em ambos os lados.

Nada funcionou até que eu mudei o comando ssh para:

ssh -L 1234:127.0.0.1:3389 user@remote

    

Answer 14

Eu tive esse problema ao tentar conectar-me via SSH com um usuário que estava autorizado a conectar-se usando o SFTP.

Por exemplo, isso estava no /etc/ssh/sshd_config :

do servidor

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

Portanto, neste caso, para usar o SSH, você terá que remover o usuário do grupo equivalente sftponly ou conectar-se usando um usuário que não esteja limitado a SFTP.

    

Answer 15

Verifique se /etc/resolv.conf está vazio no servidor para o qual você está ssh . Várias vezes achei que isso estava relacionado a um arquivo /etc/resolv.conf vazio

Se não for root, basta verificar no servidor, experimentando ping ou telnet (80) em um nome de host público, por exemplo:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

Depois de adicionar registros de servidor de nomes a /etc/resolv.conf :

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

No entanto, você também deve verificar por que /etc/resolv.conf estava vazio (geralmente é preenchido com registros do servidor de nomes pelo cliente dhcp no servidor, se aplicável.

    

Answer 16

Estou extremamente surpreso que ninguém tenha mencionado que isso pode ser um problema de DNS.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to [email protected]: unknown host (Name or service not known)

Isso pode ser apresentado se remote não puder ser resolvido ou se você inserir uma sintaxe desconhecida como eu fiz aqui, onde adicionei um user@ à lógica de encaminhamento de porta (que não funciona) .

    

Answer 17

Isso também pode ser causado por não conseguir se ligar à porta no lado local.

ssh -Nn -L 1234:remote:5678 user@remote

Este comando está tentando ligar uma porta de escuta 1234 na máquina local, que mapeia para um serviço na porta 5678 em uma máquina remota.

Se a porta 1234 na máquina local já estiver em uso por outro processo (talvez uma sessão ssh -f em segundo plano), então o ssh não poderá escutar nessa porta e o túnel falhará.

O problema é que essa mensagem de erro pode significar várias coisas, e "proibida administrativamente" dá a ideia errada às vezes. Portanto, além de verificar o DNS, os firewalls entre local e remoto e o sshd_config, verifique se a porta local já está sendo usada. Use

lsof -ti:1234

para descobrir qual processo está sendo executado em 1234. Você pode precisar do comando sudo para lsof para listar os processos de propriedade de outros usuários. Então você pode usar

ps aux | grep <pid>

para descobrir o que é esse processo.

Para obter tudo isso em um único comando:

ps aux | grep "$(sudo lsof -ti:1234)"

    

Answer 18

Eu vi esse erro no cygwin e isso deve ser verdade para o linux também e funcionou para mim. No meu caso eu tinha feito o ssh -ND *: 1234 [email protected] e quando eu conectei um navegador para aquele servidor comp-socks, ele navegou, mas na comp onde eu rodei o comando ssh eu recebi aquele erro aparecendo no o console com cada solicitação - pelo menos para um site, embora o navegador o tenha recuperado por meio do proxy ou parecesse, pelo menos na medida em que vi a idade principal. Mas fazendo essa mudança se livrou da mensagem com falha

link

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

    

Answer 19

Um outro cenário é que o serviço que você está tentando acessar não está em execução. Eu corri para esse problema no outro dia apenas para lembrar que a instância do httpd que eu estava tentando conectar tinha sido interrompida.

Seus passos para resolver o problema seria começar com o mais simples, que é ir para a outra máquina e ver se você pode se conectar localmente e, em seguida, trabalhar de volta para o seu computador cliente. Pelo menos isso permitirá que você trabalhe em que ponto a comunicação não está acontecendo. Você pode adotar outras abordagens, mas essa é uma que funcionou para mim.

    

Answer 20

Eu recebia a mesma mensagem enquanto usava SSH no Debian. Descobriu-se que o sistema remoto não tinha espaço livre. Depois de liberar algum espaço em disco e reinicializar, o túnel começou a funcionar.

    

Answer 21

Verifique se o roteador está protegido por DNS Rebinding . Meu roteador (pfsense) tem a proteção de religamento de DNS ativada por padrão. Estava causando o erro "canal aberto: falha administrativamente proibida: falha na abertura" com SSH

    

Answer 22

Eu tive o mesmo problema e percebi que era DNS. O tráfego é encapsulado, mas o pedido de DNS não. Tente editar manualmente o arquivo hosts DNS e adicione o serviço que você deseja acessar.

    

Answer 23

Meu caso:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

    

Answer 24

Recebi este erro enquanto escrevia esta entrada em meu blog :

/etc/ssh/sshd_config tinha algo como:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

Mas ~/.ssh/config teve:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

Observe a diferença em caso (capitalização) entre SSHBeyondRemote.server.com:22 e sshbeyondremote.server.com:22 .

Depois de corrigir o caso, deixei de ver o problema.

Eu estava usando:

Versão do cliente OpenSSH:

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 de março de 2016

Versão do servidor OpenSSH:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 de dezembro de 2017

Answer 25

Uma ligeira adição a um dos comentários acima: "Uma falha na resolução de DNS pode causar esse erro" - também verifique se você está ortografando seu nome de host corretamente.

Acabei de passar mais de uma hora tentando depurar todas as configurações do ssh e descobri que havia acabado de escrever incorretamente amazonaws no comando, o que é equivalente à nota de falha de resolução do DNS acima.

    

Answer 26

Outra causa de resolução de nomes: Meus / etc / hosts tinham um endereço IP incorreto para o nome do servidor (não para o host local), 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) foi 192.168.2.47. Um erro de digitação simples causado por uma reconfiguração IP anterior. Depois de consertar o / etc / hosts, a conexão do túnel funcionou perfeitamente:

ssh [email protected] -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.

    

Answer 27

A razão pela qual eu tive essa mensagem não é a mais comum, mas vale a pena mencionar. Eu tinha gerado por script uma lista de túneis e, para garantir uma apresentação em coluna, eu tinha imprimido cada último byte em dois bytes. Quando tentei abrir o encaminhamento do túnel para 192.168.66.08, ele sempre falhava, porque '08' é interpretado por gethostbyaddr como um número octal inválido:)