Error de túnel SSH: "canal 1: error de apertura: prohibido administrativamente: error de apertura"

Cuando abro este túnel ssh:

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

Recibo este error cuando intento acceder al servidor HTTP que se ejecuta en localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

¿Qué significa este error y en qué máquina puede solucionar el problema?

canal 1: error de apertura: prohibido administrativamente: error de apertura

El mensaje anterior se refiere a que su servidor SSH rechaza la solicitud de su cliente SSH de abrir un canal lateral. Esto generalmente proviene de -D, -Lo -w, ya que se requieren canales separados en la secuencia SSH para transportar los datos reenviados.

Como está utilizando -L(también aplicable a -D), hay dos opciones en cuestión que están causando que su servidor SSH rechace esta solicitud:

• AllowTcpForwarding (como mencionó Steve Buzonas)
• PermitOpen

Estas opciones se pueden encontrar en /etc/ssh/sshd_config. Debe asegurarse de que:

• AllowTCPForwarding no está presente, está comentado o se establece en yes
• PermitOpenno está presente, está comentado o se establece en any[1]

Además, si está utilizando una clave SSH para conectarse, debe verificar que la entrada correspondiente a su clave SSH ~/.ssh/authorized_keysno tiene no-port-forwardingo permitopendeclaraciones [2].

No es relevante para su comando en particular, pero también es relevante para este tema, es la PermitTunnelopción si está intentando usar la opción -w.

[1] Sintaxis completa en la página de sshd_config(5)manual.

[2] Sintaxis completa en la página de authorized_keys(5)manual.

En un caso muy extraño, también experimenté este error al intentar crear un túnel local. Mi comando fue algo como esto:

ssh -L 1234:localhost:1234 user@remote

El problema era que, en el host remoto, /etc/hostsno tenía entrada para "localhost", por lo que el servidor ssh no sabía cómo configurar el túnel. Un mensaje de error muy hostil para este caso; contento de que finalmente lo descubrí.

La lección: asegúrese de que el host remoto pueda resolver el nombre de host de destino de su túnel, ya sea a través de DNS o /etc/hosts.

Al menos una respuesta es que la máquina "remota" es inalcanzable con ssh por alguna razón. El mensaje de error es simplemente absurdo.

Si el "control remoto" no se puede resolver en el servidor, obtendrá ese error. Reemplace con una dirección IP y vea si eso resuelve su problema ...

(Básicamente la misma respuesta que la de Neil, pero ciertamente encontré que ese era el problema de mi lado) [Tenía un alias para el nombre de la máquina en mi ~/.ssh/configarchivo, y la máquina remota no sabía nada de ese alias ...

Este error aparece definitivamente cuando usa las opciones ssh ControlPathy ControlMasteral compartir una conexión de socket para ser reutilizada entre varias conexiones de clientes (de un cliente al mismo usuario @ servidor). Abrir demasiados (lo que sea que signifique, en mi caso ~ 20 conexiones) produce este mensaje. Cerrar cualquier conexión previa me permite abrir más nuevo, nuevamente hasta el límite.

"prohibido administrativamente" es un indicador de mensaje ICMP específico que se reduce a "El administrador desea explícitamente que se bloquee esta conexión".

Verifique la configuración de iptables.

Un problema similar

Otra posible pista

Tuve el mismo problema al usar ~/.ssh/authorized_keyscon permitopen.

Como uso autosshpara crear un túnel, necesito dos puertos:

• uno para conexión (10000),
• uno para monitoreo (10001).

Del lado del cliente

Esto me dio un problema similar con el puerto de monitoreo:

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

Recibí ese mensaje (después de 10 minutos):

channel 2: open failed: administratively prohibited: open failed

En el lado remoto

Mi /var/log/auth.logcontenido:

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

En mi ~/.ssh/authorized_keys(lado remoto) tuve esto:

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

Cómo resolverlo

Resolví esto reemplazando localhostinstancias con 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 SSH no entiende que localhostes un acceso directo a 127.0.0.1, por lo tanto, el mensaje auth.logy el mensaje administrativamente prohibido .

Lo que entiendo aquí es que administrativamente significa "debido a una configuración específica en el lado del servidor".

Esto también sucede cuando /etc/sshd_configtiene

AllowTcpForwarding no 

conjunto. Cambie a yespara permitir el reenvío de TCP.

En mi caso, tuve que reemplazar localhostcon 127.0.0.1en:

ssh -L 1234:localhost:3389 user@remote

para que funcione

Intenté rdesktop -L localhost:1234seguir las instrucciones de Amazon para conectarme a AWS EC2 a través de túneles SSH . Intenté cambiar /etc/ssh/sshd_config(tanto el cliente como el servidor ejecutan Ubuntu 16.04 LTS) según la respuesta más votada. También verifiqué que localhosthay en /etc/hostsambos lados.

Nada funcionó hasta que cambié el sshcomando en sí a:

ssh -L 1234:127.0.0.1:3389 user@remote

Se necesita alguna actividad de solución de problemas para encontrar una respuesta definitiva:

• compruebe que el reenvío de puertos esté habilitado en la configuración ssh del usuario,
• habilitar la verbosidad de ssh (-v),
• compruebe los registros ssh en el host local y los registros seguros en el remoto,
• probar diferentes puertos remotos,
• verifique la configuración de iptables (como dijo Shadur).

Recibí este error una vez por poner el control remoto en el parámetro -L, también el 0.0.0.0 es redundante, puede omitirlo con los mismos resultados, y creo que debería agregar el -g para que funcione.

Esta es la línea que uso para hacer túneles: 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.

Esto también puede ser causado por no poder vincularse al puerto en el lado local.

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

Este comando está intentando vincular un puerto de escucha 1234 en la máquina local, que se asigna a un servicio en el puerto 5678 en una máquina remota.

Si el puerto 1234 en la máquina local ya está en uso por otro proceso (tal vez una sesión ssh -f en segundo plano), entonces ssh no podrá escuchar en ese puerto y el túnel fallará.

El problema es que este mensaje de error puede significar cualquiera de varias cosas, y "prohibido administrativamente" a veces da una idea equivocada. Entonces, además de verificar DNS, firewalls entre local y remoto, y sshd_config, verifique si el puerto local ya está en uso. Utilizar

lsof -ti:1234

para averiguar qué proceso se está ejecutando en 1234. Es posible que necesite sudo para que lsof enumere los procesos que pertenecen a otros usuarios. Entonces puedes usar

ps aux | grep <pid>

para descubrir cuál es ese proceso.

Para obtener todo esto en un comando:

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

Recibí el mismo mensaje al intentar hacer un túnel. Hubo un problema con el servidor DNS en el lado remoto. El problema se resolvió cuando volvió a funcionar.

Estoy extremadamente sorprendido de que nadie haya mencionado que esto podría ser un problema de DNS.

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

Esto podría presentarse si remoteno se puede resolver o si ha ingresado una sintaxis desconocida como la que he hecho aquí, donde he agregado una user@a la lógica de reenvío de puertos (que no funcionará).

En mi caso, el problema se debió a solicitar un túnel sin acceso de shell mientras el servidor tenía como objetivo forzar un cambio de contraseña en mi cuenta. Debido a la falta de un shell, no pude ver eso y solo recibí el error

channel 2: open failed: administratively prohibited: open failed  

La configuración de mi túnel fue la siguiente:

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

El error se mostró al iniciar sesión directamente en el servidor (sin -N -f):

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

Resolví el problema iniciando sesión con acceso de shell y cambiando la contraseña. Entonces podría simplemente usar túneles sin acceso a shell nuevamente.

Tuve este problema al intentar conectarme a través de SSH con un usuario que solo estaba autorizado para conectarse usando SFTP.

Por ejemplo, esto estaba en el servidor /etc/ssh/sshd_config:

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

Entonces, en este caso, para usar SSH, deberá eliminar al usuario del sftponlygrupo equivalente o conectarse utilizando un usuario que no esté limitado a SFTP.

Comprueba si /etc/resolv.confestá vacío en el servidor al que estás sshyendo. Varias veces encontré que esto estaba relacionado con un /etc/resolv.confarchivo vacío

Si no es root, puede verificar el servidor probando algunos pingo telnet(80) en un nombre de host público, es decir:

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

Después de agregar registros de servidor de nombres 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

Sin embargo, también debe verificar por qué /etc/resolv.confestaba vacío (el cliente dhcp en el servidor generalmente lo rellena con registros del servidor de nombres, si corresponde).

Recibía el mismo mensaje mientras SSH hacía Tunel a Debian. Resultó que el sistema remoto no tenía espacio libre. Después de liberar espacio en el disco y reiniciar, el túnel comenzó a funcionar.

Vi este error en Cygwin y esto también debería ser cierto para Linux y funcionó para mí. En mi caso, había hecho ssh -ND *: 1234 user@127.0.0.1 y cuando conecté un navegador a ese servidor de comp-socks, navegué, pero en la comp donde ejecuté ese comando ssh, apareció ese error en la consola con cada solicitud, al menos para un sitio, aunque el navegador lo recuperó a través del proxy o parecía, al menos en la medida en que vi la edad principal. Pero al hacer este cambio se libró del mensaje fallido

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

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

Otro escenario es que el servicio al que está intentando acceder no se está ejecutando. Me encontré con este problema el otro día solo para recordar que la instancia httpd a la que intentaba conectarme se había detenido.

Sus pasos para resolver el problema serían comenzar con el más simple, que es ir a la otra máquina y ver si puede conectarse localmente y luego volver a trabajar con su computadora cliente. Al menos esto le permitirá averiguar en qué punto la comunicación no está ocurriendo. Puede tomar otros enfoques, pero este es uno que funcionó para mí.

Verifique su enrutador para la protección de rebobinado de DNS . Mi enrutador (pfsense) tiene la Protección de enlace DNS habilitada de forma predeterminada. Estaba causando el error 'abrir canal: falló prohibido administrativamente: abrir falló' con SSH

Tuve el mismo problema y me di cuenta de que era DNS. El tráfico se canaliza pero la solicitud de DNS no. Intente editar su archivo de hosts DNS manualmente y agregue el servicio al que desea acceder.

Mi 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)

Recibí este error al escribir esta entrada en mi blog :

/etc/ssh/sshd_config tenía algo como:

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

Pero ~/.ssh/configtenía:

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

Tenga en cuenta la diferencia en mayúsculas y minúsculas (mayúsculas) entre SSHBeyondRemote.server.com:22 y sshbeyondremote.server.com:22 .

Una vez que arreglé el caso, ya no vi el problema.

Estaba usando:

Versión del cliente OpenSSH:

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

Versión del servidor OpenSSH:

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

Otra causa de resolución de nombres: Mi / etc / hosts tenía una dirección IP errónea para el nombre del servidor (no para localhost), como esta:

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.

La razón por la que recibí ese mensaje no es la más común, pero vale la pena mencionarla. Había generado por script una lista de túneles, y para asegurar una presentación en columna, había impreso cada último byte en dos bytes. Cuando intenté abrir el reenvío del túnel a 192.168.66.08, siempre fallaba, porque gethostbyaddr interpreta '08' como un número octal no válido :)

Parece que hay muchas causas posibles para este mensaje. En mi caso, fue una incapacidad para acceder al control remoto porque no había proporcionado el archivo de claves correctamente.

La -Lopción agrega un salto SSH implícito (efectivamente utilizando el host SSH explícito como servidor de bastión / salto). Puede ser más fácil depurar esto realizando el salto explícitamente y creando un shell de inicio de sesión en la máquina de destino usando "proxycommand".

Una vez que esto funciona, puede reenviar el puerto según la máquina de destino localhost(suponiendo que pueda iniciar sesión en sí mismo):

-N -L 1234:localhost:1234