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

185

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?

Neil
fuente
Tal vez me falta algo, pero ¿por qué estás intentando acceder a un servidor web utilizando un cliente ssh?
Faheem Mitha
¿Por qué reenvía X11 (opción -X) aquí? Si solo desea reenviar HTTP, esto no es necesario. Y como nota al margen, IMHO ssh podría ser la solución incorrecta para hacer que un servidor web esté disponible en múltiples puertos.
Marcel G
29
Encontré que esto significa "No se puede resolver el nombre de host remote" en mi caso.
RobM
3
Como puede ver en la docena de respuestas a continuación, el mensaje de error, a pesar de parecer muy específico, debe entenderse como un error genérico. En general, la solución es abrir un shell en el control remoto e intentar la misma conexión, para ver la causa real. Encontrará en las respuestas a continuación las causas reales más comunes.
Stéphane Gourichon
Un error de resolución DNS puede causar este error además de la conexión se puede congelar hasta que el tiempo de espera: superuser.com/a/700677
user423430

Respuestas:

122

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.

hyperair
fuente
Aquí lo que agregué específicamente en sshd_config para que funcione: TCPKeepAlive sí AllowTCPForwarding sí PermitOpen cualquiera Tengo algunos "errores de apertura" pero parece algo normal. Las cosas funcionan muy bien.
Pierre Thibault
44
Un caso de esquina para tener en cuenta: puede obtener este error al intentar crear un dispositivo tap / tun con SSH y SSH lo permite, pero el núcleo no. Esto puede ocurrir en contenedores LXC. Consulte blog.felixbrucker.com/2015/10/01/… para conocer los detalles exactos, pero en ese caso es posible que desee agregar lxc.cgroup.devices.allow = c 10:200 rwma la configuración de su contenedor y asegurarse de que, si /dev/net/tunno existe, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunse ejecute en el arranque en el contenedor.
Azendale
@Azendale, eso es interesante, gracias. ¿Produce exactamente el mismo mensaje de error o algo ligeramente diferente?
hyperair
1
@ St.Antario, le AllowTcpForwardingpermite reenviar puertos TCP a través de SSH, que es lo -L 0.0.0.0:8984:remote:8983que solicita el parámetro. Si AllowTcpForwardingse establece en no, SSH rechazará la solicitud de reenvío de puerto, haciendo que vea ese error.
hyperair el
2
Intenté editar las mayúsculas de AllowTCPForwardingto AllowTcpForwarding, pero SE quiere cambiar al menos 6 caracteres. Tan solo señalando que el caso correcto es la Tcpversión, como se usó correctamente la primera vez.
dbreaux
51

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.

Cobbzilla
fuente
2
Gracias, este fue el problema para mí. Creé el nombre de host para la IP localmente pero no en el servidor ssh remoto.
dev_feed
2
"el nombre de host de destino de su túnel" es un poco difícil de descifrar. ¿Puede dar un ejemplo viable y concreto que me permita tomar su ejemplo y reemplazar el "nombre de host de destino" en su ejemplo con mi nombre de host de destino (una vez que entiendo lo que quiere decir con eso) y tener este trabajo?
Terrence Brannon
1
Ni siquiera estoy seguro de que tu comentario tenga sentido. Usted dice que la máquina remota no tenía entrada para localhost. Pero luego diga que el host remoto debe resolver el nombre de host de destino, no el nombre de host local. Una vez más, sería útil un ejemplo concreto completo de la situación anterior y posterior.
Terrence Brannon
1
@TerrenceBrannon en el comando anterior, "localhost" es el nombre de host de destino del túnel . Al crear un túnel SSH, el comando ssh primero inicia sesión en el sistema remoto ( user@remote), luego desde el extremo remoto, establece túneles a los hosts de destino enumerados (en el comando anterior esto es localhost). 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 resolverse localhost, recibirá este mensaje de error.
Cobbzilla
1
En mi caso, fue tan simple como haber escrito mal el nombre de host objetivo, por lo que, por supuesto, no se resolvió, pero mis ojos no vieron el error tipográfico durante demasiado tiempo.
Randall
25

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.

Neil
fuente
2
No, no lo es; Uso icmp-admin-prohibido como el indicador de rechazo en las configuraciones de firewall todo el tiempo.
Shadur 01 de
99
+1, el mensaje prohibido administrativamente haría creer que se trata de un bloqueo de firewall, sin embargo, recibirá el mismo mensaje cuando no hay bloqueo de firewall pero la apertura falla porque no hay una ruta hacia el host remoto.
Steve Buzonas
1
Acabo de pasar varios minutos buscando este problema, cuyo mensaje no tiene ningún sentido en mi contexto. Afortunadamente, es bastante claro al verificar los archivos de registro de la estación central.
yaccz
De hecho, si "remoto" es inalcanzable, porque está inactivo, fuera de línea, no existe, el nombre de host no se resuelve, verá este mensaje de error.
Michael Martinez
18

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

jacquesjtheron
fuente
También puede ver el mismo error al usar -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.
timss
10

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.

Matej Kovac
fuente
Vine aquí buscando dónde establecer este límite multiplex ControlMaster. Si alguien lo sabe, son más que bienvenidos a compartir.
clacke
1
clacke: de acuerdo con bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 puede agregar un parámetro MaxSession en el archivo / etc / ssh / sshd_config para configurarlo. De acuerdo con la página del manual, esto se establece en 10 de forma predeterminada.
Oliver
@oliver: confirmando, MaxSession funciona, gracias. topado a 64 en mi libro de trabajo.
Matej Kovac
2
Ten cuidado, no es MaxSessionpero MaxSessions. Aunque hay algunas protecciones, no rompa la configuración de su servidor ssh ...
Stéphane Gourichon
8

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

Shadur
fuente
55
No necesariamente. El mensaje se genera cuando el host no puede atender la solicitud. El caso generalmente se debe a que el administrador ha bloqueado la conexión, pero también puede ser que no esté explícitamente bloqueado pero no haya una ruta al host deseado. AFAIK sshno 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.
Steve Buzonas
2
UH no. Hay una diferencia clara entre el tipo de respuesta ICMP que dice "no hay ruta al host" y una que dice "prohibido administrativamente", y a menos que alguien deliberadamente haya configurado mal un enrutador, este último significa exactamente lo que dice en la lata.
Shadur
1
Acabo de ser 'administrativamente prohibido' cuando utilizo un nombre de host que no se resolvió, por lo que parece ser un problema general. ¿Quizás ssh está haciendo alguna traducción?
Ganesh Sittampalam
5

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

lauhub
fuente
localhost probablemente asignado a :: 1 (ipv6) y no estaba escuchando allí por alguna razón
Jo Rhett
4

Esto también sucede cuando /etc/sshd_configtiene

AllowTcpForwarding no 

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

usuario578125
fuente
4

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
tinlyx
fuente
Muchas gracias!
Thibaut Barrère
3

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

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.
Marciano
fuente
3

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)"
Mnebuerquo
fuente
2

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.

Leonardo Brunnet
fuente
2

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 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á).

Torxed
fuente
2

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.

Pieter Van Gorp
fuente
1

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.

Miguel
fuente
1

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

Ender
fuente
1

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.

SlavaSt
fuente
0

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/

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
barlop
fuente
El túnel AFAIK está habilitado de manera predeterminada porque la desactivación no agrega ninguna capa de seguridad, principalmente solo un inconveniente de agregar un túnel de terceros. Tengo un problema similar al tratar de proxy a servidores internos desde una ubicación fuera del sitio y el túnel está habilitado + iptables enjuagado con la acción predeterminada ACCEPT.
Steve Buzonas
@SteveBuzonas Veo esto en / etc / sshd_config, así que a) no desactiva el túnel b) en cuanto a mi respuesta, la solución puede no ser una buena idea. Esto es lo que sshd_config dice acerca de esa opción # Para deshabilitar las contraseñas de texto sin cifrado, ¡cambie a no aquí! #PermitTunnel no
barlop
@SteveBuzonas comprueba tu, probablemente esté configurado en no y puedes hacer un túnel, ya que de hecho el túnel está habilitado de forma predeterminada.
barlop
Estaba pensando AllowTCPForwarding: el comentario del que está hablando # To disable tunneled clear textse refiere a que PasswordAuthenticationse establece en no, PermitTunneles 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.
Steve Buzonas
0

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

Andre M
fuente
Un consejo general útil pero no una respuesta a la pregunta planteada.
Kyle Jones el
0

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

efecto
fuente
0

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.

Datos
fuente
0

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

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
Zach Pfeffer
fuente
1
Si va a vincular, promocionar, citar o referirse a algo con lo que está afiliado, debe revelar explícitamente esa afiliación. Decir "al armar (enlace)" no es suficiente (porque no entendí lo que significaba hasta después de descubrir que estabas enlazando a tu propio blog); tener una URL que coincida con su nombre de usuario de Stack Exchange no es suficiente. Referencias: Cómo no ser un spammer ,  evitar la autopromoción abierta , ... (Cont.)
Scott
(Continúa) ... y ¿ Cuándo debemos hacer cumplir el requisito de afiliación?    Puede mencionar su blog, su empleador, cualquier software conocido que haya desarrollado, cualquier libro que haya escrito, cualquier otro proyecto al que esté o haya estado afiliado, etc., en su página de perfil de usuario .
Scott
0

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.

Fjor
fuente
0

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

Philippe De Muyter
fuente
0

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
sin bar
fuente