desarrollo-web-br-bd.com

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?

210
Neil

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, -L O -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
  • PermitOpen no 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 en ~/.ssh/authorized_keys No tenga no-port-forwarding O permitopen declaraciones [2] .

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

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

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

134
hyperair

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

El problema era, en el host remoto, /etc/hosts no 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.

55
cobbzilla

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.

27
Neil

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 parte) [Tenía un alias para el nombre de la máquina en mi ~/.ssh/config file - y la máquina remota no sabía nada de ese alias ...

19
jacquesjtheron

Este error aparece definitivamente cuando usa las opciones ssh ControlPath y ControlMaster para compartir una conexión de socket que se reutilizará entre varias conexiones de cliente (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.

11
Matej Kovac

"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.

8
Shadur

En mi caso, tuve que reemplazar localhost con 127.0.0.1 en:

ssh -L 1234:localhost:3389 [email protected]

para que funcione.

Estaba intentando rdesktop -L localhost:1234 siguiendo Amazon's instrucciones sobre cómo conectarse a AWS EC2 a través de túneles SSH . Había tratado de 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 localhost está en /etc/hosts a ambos lados.

Nada funcionó hasta que cambié el comando ssh en sí mismo a:

ssh -L 1234:127.0.0.1:3389 [email protected]
6
tinlyx

Un problema similar

Otra posible pista

Tuve el mismo problema usando ~/.ssh/authorized_keys con permitopen.

Como uso autossh para 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 [email protected]

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

channel 2: open failed: administratively prohibited: open failed

En el lado remoto

Mi /var/log/auth.log contenido:

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 localhost instancias 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 localhost es un acceso directo a 127.0.0.1, de ahí el mensaje en auth.log y el mensaje prohibido administrativamente.

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

5
lauhub

Esto también sucede cuando /etc/sshd_config tiene

AllowTcpForwarding no 

conjunto. Cambie a yes para permitir TCP reenvío.

4
user578125

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

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).
3
Marco Solieri

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

ssh -Nn -L 1234:remote:5678 [email protected]

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. Por lo tanto, además de verificar DNS, firewalls entre locales y remotos, 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 son propiedad de 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)"
3
Mnebuerquo

En mi caso, el problema se debió a solicitar un túnel sin acceso a Shell mientras el servidor intentaba 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 Shell y cambiando la contraseña. Entonces podría simplemente usar túneles sin acceso a Shell nuevamente.

2
Pieter Van Gorp

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 [email protected]: unknown Host (Name or service not known)

Esto podría presentarse si remote no se puede resolver o si ha ingresado una sintaxis desconocida como la que he hecho aquí donde he agregado un [email protected] a la lógica de reenvío de puertos (que no funcionará).

2
Torxed

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.

2
Leonardo Brunnet

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 grupo sftponly equivalente o conectarse utilizando un usuario que no esté limitado a SFTP.

1
Mike

Recibía el mismo mensaje mientras SSH hacía un túnel 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.

1
SlavaSt

Compruebe si /etc/resolv.conf Está vacío en el servidor al que está ssh-. Varias veces encontré que esto estaba relacionado con un archivo vacío /etc/resolv.conf

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

[email protected] ~ # 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:

[email protected] ~ # 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.conf Estaba vacío (el cliente dhcp en el servidor generalmente lo llena con registros del servidor de nombres, si corresponde.

1
Ender

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/config tení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 case (mayúscula) 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
0
Zach Pfeffer

Vi este error en Cygwin y esto también debería ser cierto para Linux y funcionó para mí. En mi caso, hice ssh -ND *: 1234 [email protected] 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 :
[email protected]:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
[email protected]:~# service ssh restart
or

[email protected]:~# /etc/init.d/ssh restart
0
barlop

Una pequeña adición a uno de los comentarios anteriores: "Un error de resolución de DNS puede causar este error", también asegúrese de escribir correctamente su nombre de host.

Acabo de pasar más de una hora tratando de depurar todas las configuraciones de ssh y resulta que acabo de escribir mal amazonaws en el comando que es equivalente a la nota de falla de resolución DNS anterior.

0
Brad Dwyer

El firmware del enrutador Asus RT68U (Merlin Asus) tiene una configuración que permite el reenvío de puertos SSH, que debe habilitarse:

enter image description here

El reenvío dinámico de puertos se configuró como se describe en: Solución de problemas del túnel Dyamic

0
gatorback

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

0

Verifique su enrutador para DNS Rebinding protección. 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

0
meffect

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 keyfile correctamente.

La opción -L Agrega un salto SSH implícito (usando efectivamente el Host SSH explícito como un servidor bastion/jump). 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 en función de la máquina de destino localhost (suponiendo que pueda iniciar sesión en sí mismo):

-N -L 1234:localhost:1234
0
nobar

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)
0
diyism

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

0
Fjor

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

0
Data

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í.

0
Andre M