¿A qué se refieren los números de canal en el mensaje de error ssh?


12

En el siguiente ejemplo, ¿a qué corresponden los números de canal? ¿Cuáles están en el servidor? ¿Cuáles están en el cliente?

  $ ssh -L1570:127.0.0.1:8899 root@thehost
    Password:
    Last login: Fri Aug  9 13:08:44 2013 from theclientip
    Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
    You have new mail.
    # channel 2: open failed: administratively prohibited: open failed
    channel 3: open failed: administratively prohibited: open failed
    channel 2: open failed: administratively prohibited: open failed

El cliente ssh se ejecuta en Windows 7 y el servidor tiene un servidor Tomcat en el puerto 8899.

Tomcat no está escuchando en 127.0.0.1 en la máquina remota, por lo que si cambio el comando al ssh -L1570:thehostpublicip:8899 root@thehostpuerto hacia adelante funciona. Así que sé que el reenvío de puertos parece estar funcionando bien en el servidor.

mi archivo de configuración sshd contiene las siguientes dos líneas:

# Port forwarding
AllowTcpForwarding yes

# If port forwarding is enabled, specify if the server can bind to INADDR_ANY.
# This allows the local port forwarding to work when connections are received
# from any remote host.
GatewayPorts yes

Estoy tratando de configurar el reenvío de puertos para otro proceso que no sea Tomcat y recibo los mensajes de error similares a los de arriba, así que estoy tratando de entender el significado de los mensajes de error.

Respuestas:


21

De la documentación del Protocolo SSH , con respecto a los canales:

Todas las sesiones de terminal, conexiones reenviadas, etc., son canales. Cualquiera de los lados puede abrir un canal. Múltiples canales se multiplexan en una sola conexión.

Los canales se identifican por números en cada extremo. El número que hace referencia a un canal puede ser diferente en cada lado. Las solicitudes para abrir un canal contienen el número de canal del remitente. Cualquier otro mensaje relacionado con el canal contiene el número de canal del destinatario para el canal.

Los canales están controlados por flujo. No se pueden enviar datos a un canal hasta que se reciba un mensaje para indicar que hay espacio disponible en la ventana.

Reenvío de puertos

El comando que tienes se ve bien. ¿Está seguro de que el servicio al que intenta conectarse está activo y acepta conexiones? Los errores del canal parecen indicar que no lo es.

¿Cuáles son mis canales activos?

Si tiene una sshconexión activa , puede usar la siguiente combinación de teclas para obtener ayuda:

Shift+ ~seguido de Shift+?

$ ~?
Supported escape sequences:
  ~.  - terminate connection (and any multiplexed sessions)
  ~B  - send a BREAK to the remote system
  ~C  - open a command line
  ~R  - Request rekey (SSH protocol 2 only)
  ~^Z - suspend ssh
  ~#  - list forwarded connections
  ~&  - background ssh (when waiting for connections to terminate)
  ~?  - this message
  ~~  - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
debug2: channel 2: written 480 to efd 8

Luego puede usar esta combinación de teclas para obtener una lista de los canales activos:

Shift+ ~seguido de Shift+#

$ ~#
The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
debug2: channel 2: written 93 to efd 8

4

Si tomcat no está escuchando en loopback (127.0.0.1), un puerto hacia adelante le dará el mensaje de error que ha estado recibiendo.

Si hago un ssh, con un puerto hacia un puerto que no escucha (por ejemplo: ssh -L1234:127.0.0.1:9999 10.0.0.1- donde ningún proceso en 10.0.0.1 está vinculado al puerto 9999 en 127.0.0.1), obtengo el mismo error:

channel 2: open failed: administratively prohibited: open failed

Puede averiguar a qué canal se hace referencia agregando -vvva su ssh

ssh -vvv -L1570:127.0.0.1:8899 root@thehost

En qué puerto está escuchando el "otro proceso" (y en qué direcciones IP), netstat -tulpnconfirmará qué puertos y procesos IP están utilizando en sus servidores, el -L tendrá que apuntar a una dirección y puerto en el que está escuchando.


No puedo reproducir lo anterior. ¿Está habilitando parámetros ssh en el cliente y / o servidor para obtener esto?
slm

No (configuraciones estándar 'listas para usar' en ambos lados). Por lo que puedo averiguar, obtienes connect failed: Connection refusedcuando un firewall niega la conexión. administratively prohibited: open failedestá en un host sin firewall.
Drav Sloan el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.