.png)
Tengo un servidor Linux ejecutando openssh. Puedo conectarme tanto desde la LAN local como de forma remota. Sin embargo, hay un cliente (una computadora portátil con Windows 10) que solo puede conectarse localmente. Cuando intento conectarme de forma remota, se acepta la autenticación, pero el cliente ssh de la computadora portátil se bloquea y se debe eliminar con Process Explorer. Pensé que el problema podría ser:
- Firewall de Windows: no. Lo apagué, obtuve el mismo comportamiento.
- Cliente ssh (cygwin) - No. Obtuve el mismo comportamiento con PuTTY.
- Windows 10: no. Puedo conectarme exitosamente de forma remota desde otra máquina Win10.
Probé una instalación nueva de cygwin y putty.
Intenté ejecutar ssh con varias opciones -v y comparar el resultado con la otra máquina Win10 que puede conectarse. El resultado fue idéntico, hasta cierto punto:
Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
>>> "bad" machine hangs here
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)
Welcome to Linux Mint
En raras ocasiones, ha llegado más lejos, una o dos veces incluso hasta el mensaje de bienvenida, pero la conexión nunca responde a la escritura.
Intenté ejecutar sshd -d manualmente en el servidor y comparar el resultado entre una sesión remota "mala" y una "buena" de otro cliente. La salida es idéntica.
Para resumir: no parece ser el Firewall de Windows, ni el software del cliente, ni Win10, ni el reenvío de puertos al servidor, ni DNS, ni el servidor mismo. El problema es sólo esta máquina cliente, y sólo cuando se conecta desde fuera de la LAN local. Se está autenticando exitosamente. Y la máquina cliente está ejecutando el mismo cliente OS/ssh que otra máquina que no tiene el problema, y tampoco puedo ver nada en los registros que lo distinga.
EDITAR: También debo mencionar que la conexión ssh a otros servidores remotos funciona bien desde todas las máquinas. Parece ser solo este par servidor/cliente, y solo cuando se conecta de forma remota.
ACTUALIZACIÓN: consulte mis comentarios inmediatamente a continuación para obtener más información; el problema parece ser específico de la red local.
¿Qué pasos adicionales puedo seguir para depurarlo?
Respuesta1
Me parece que en el momento en que se cuelga, los paquetes TCP del servidor dejan de llegar al cliente. La razón por la que creo que esto es porque a veces se bloquea en diferentes puntos y porque el problema varía según se cambia la configuración de la red. Por ejemplo, podría tratarse de alguna interacción no deseada entre el reenvío de puertos, NAT y/o firewalls. Pero la pregunta es cómo diagnosticar por qué esto sucede en un cliente pero no en otro. Se me ocurren dos enfoques:
Tu podrías intentarmonitoreo de paquetesen el servidor y el cliente y en puntos a lo largo de la ruta para verificar si los paquetes realmente se están perdiendo y en qué punto.
Podría experimentar para intentar encontrar una relación entre la configuración de red y la existencia o no existencia del problema en diferentes clientes. Intercambie todas o algunas configuraciones de red y direcciones IP entre un cliente que funciona y uno que no funciona para ver si intercambia el problema.