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?
remote
" en mi caso.Respuestas:
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 enyes
PermitOpen
no está presente, está comentado o se establece enany
[1]Además, si está utilizando una clave SSH para conectarse, debe verificar que la entrada correspondiente a su clave SSH
~/.ssh/authorized_keys
no tieneno-port-forwarding
opermitopen
declaraciones [2].No es relevante para su comando en particular, pero también es relevante para este tema, es la
PermitTunnel
opció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.fuente
lxc.cgroup.devices.allow = c 10:200 rwm
a la configuración de su contenedor y asegurarse de que, si/dev/net/tun
no existe,mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tun
se ejecute en el arranque en el contenedor.AllowTcpForwarding
permite reenviar puertos TCP a través de SSH, que es lo-L 0.0.0.0:8984:remote:8983
que solicita el parámetro. SiAllowTcpForwarding
se establece enno
, SSH rechazará la solicitud de reenvío de puerto, haciendo que vea ese error.AllowTCPForwarding
toAllowTcpForwarding
, pero SE quiere cambiar al menos 6 caracteres. Tan solo señalando que el caso correcto es laTcp
versión, como se usó correctamente la primera vez.En un caso muy extraño, también experimenté este error al intentar crear un túnel local. Mi comando fue algo como esto:
El problema era que, 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
.fuente
user@remote
), luego desde el extremo remoto, establece túneles a los hosts de destino enumerados (en el comando anterior esto eslocalhost
). Al hacer esto, utiliza el esquema de resolución de nombre de host en el host remoto . Entonces, si la máquina en la que SSH'd no puede resolverselocalhost
, recibirá este mensaje de error.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.
fuente
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/config
archivo, y la máquina remota no sabía nada de ese alias ...fuente
-D
(DynamicForward) como un proxy SOCKS en un navegador. Es decir, tratando de acceder a un sitio web que el host del túnel no puede resolver.Este error aparece definitivamente cuando usa las opciones ssh
ControlPath
yControlMaster
al 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.fuente
MaxSession
peroMaxSessions
. Aunque hay algunas protecciones, no rompa la configuración de su servidor ssh ..."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.
fuente
ssh
no tiene lógica para determinar por qué falló una conexión, solo asume que si está intentando conectarse, entonces existe, y si no puede llegar allí, la conexión debe haberse bloqueado intencionalmente.Un problema similar
Otra posible pista
Tuve el mismo problema al usar
~/.ssh/authorized_keys
conpermitopen
.Como uso
autossh
para crear un túnel, necesito dos puertos:Del lado del cliente
Esto me dio un problema similar con el puerto de monitoreo:
Recibí ese mensaje (después de 10 minutos):
En el lado remoto
Mi
/var/log/auth.log
contenido:En mi
~/.ssh/authorized_keys
(lado remoto) tuve esto:Cómo resolverlo
Resolví esto reemplazando
localhost
instancias con127.0.0.1
:Parece que SSH no entiende que
localhost
es un acceso directo a127.0.0.1
, por lo tanto, el mensajeauth.log
y el mensaje administrativamente prohibido .Lo que entiendo aquí es que administrativamente significa "debido a una configuración específica en el lado del servidor".
fuente
Esto también sucede cuando
/etc/sshd_config
tieneconjunto. Cambie a
yes
para permitir el reenvío de TCP.fuente
En mi caso, tuve que reemplazar
localhost
con127.0.0.1
en:para que funcione
Intenté
rdesktop -L localhost:1234
seguir 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é quelocalhost
hay en/etc/hosts
ambos lados.Nada funcionó hasta que cambié el
ssh
comando en sí a:fuente
Se necesita alguna actividad de solución de problemas para encontrar una respuesta definitiva:
fuente
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
fuente
Esto también puede ser causado por no poder vincularse al puerto en el lado local.
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
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
para descubrir cuál es ese proceso.
Para obtener todo esto en un comando:
fuente
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.
fuente
Estoy extremadamente sorprendido de que nadie haya mencionado que esto podría ser un problema de DNS.
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 unauser@
a la lógica de reenvío de puertos (que no funcionará).fuente
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
La configuración de mi túnel fue la siguiente:
El error se mostró al iniciar sesión directamente en el servidor (sin -N -f):
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.
fuente
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
:Entonces, en este caso, para usar SSH, deberá eliminar al usuario del
sftponly
grupo equivalente o conectarse utilizando un usuario que no esté limitado a SFTP.fuente
Comprueba si
/etc/resolv.conf
está vacío en el servidor al que estásssh
yendo. Varias veces encontré que esto estaba relacionado con un/etc/resolv.conf
archivo vacíoSi no es root, puede verificar el servidor probando algunos
ping
otelnet
(80) en un nombre de host público, es decir:Después de agregar registros de servidor de nombres a
/etc/resolv.conf
:Sin embargo, también debe verificar por qué
/etc/resolv.conf
estaba vacío (el cliente dhcp en el servidor generalmente lo rellena con registros del servidor de nombres, si corresponde).fuente
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.
fuente
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 [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/
fuente
ACCEPT
.AllowTCPForwarding
: el comentario del que está hablando# To disable tunneled clear text
se refiere a quePasswordAuthentication
se establece en no,PermitTunnel
es una configuración para permitir túneles de red de capa 2 o capa 3 a través de tun / tap y el valor predeterminado es no. Las opciones L, R y D utilizan el reenvío TCP y no un dispositivo para tunelizar.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í.
fuente
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
fuente
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.
fuente
Mi caso:
fuente
Recibí este error al escribir esta entrada en mi blog :
/etc/ssh/sshd_config
tenía algo como:Pero
~/.ssh/config
tenía: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:
Versión del servidor OpenSSH:
fuente
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:
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:
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.
fuente
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 :)
fuente
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
-L
opció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):fuente