☰

SSH no se conecta: se agotó el tiempo de espera de la operación

tag-icon • tag-icon ssh osx-yosemite ubuntu-14.04
SSH no se conecta: se agotó el tiempo de espera de la operación

Desde esta mañana recibo el siguiente mensaje de error al intentar conectarme a mi control remotoUbuntu 14.04 LTSmáquina a través sshde unMacBook Air Yosemite 10.10.1.

ssh_exchange_identification: read: Operation timed out

Cuando se utiliza -vvvla bandera, aparece el siguiente mensaje detallado

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /Users/felix/.ssh/id_rsa type -1
debug1: identity file /Users/felix/.ssh/id_rsa-cert type -1
debug1: identity file /Users/felix/.ssh/id_dsa type -1
debug1: identity file /Users/felix/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

Durante muchos meses esta conexión funcionó perfectamente bien. Nunca he experimentado ningún problema. Otras soluciones como las encontradasaquíyaquíno ayudó.

¿Alguna sugerencia sobre cómo solucionar este problema?

Respuesta1

debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

Según su seguimiento de depuración, está logrando conectarse al servidor SSH remoto y el servidor no interrumpe la conexión, pero no envía su cadena de identificación de software. Esto es lo primero que hacen el cliente y el servidor, y se hace en texto claro.

Creo que el problema se reducirá a una de tres cosas:

  1. Algún dispositivo de red entre usted y el servidor está interfiriendo con la conexión. Por ejemplo, si el host remoto está detrás de un enrutador NAT, es posible que el reenvío de puerto para el puerto 22 esté configurado incorrectamente y que se esté conectando al servicio incorrecto.

  2. Es posible que el programa del servidor SSH en el host remoto esté bloqueado o no funcione correctamente. He visto que sucede este tipo de cosas, por ejemplo, cuando el host está muy sobrecargado o tiene poca memoria virtual. O el servidor puede estar usando algo comoEnvoltorios TCPy está realizando una consulta de DNS en la IP de su cliente que está tardando mucho en resolverse.

  3. El host remoto está configurado de una manera inusual y el servicio que se ejecuta en el puerto 22 no es un servidor SSH.

Si puede acceder al servidor, concentre su resolución de problemas allí. Busque los registros del servidor ssh (deberían estar ahí) /var/logy vea si ha registrado algo sobre estos intentos fallidos de conexión. Intente ejecutar ssh en localhost desde el servidor y vea si funciona correctamente.

Si tiene acceso raíz al servidor, puede intentar iniciar una instancia de depuración para sshdver qué registra cuando su cliente se conecta. Detenga el servidor normal sshdy, en una ventana de terminal raíz, ejecute /path/to/sshd -d. Esto ejecutará una copia de sshd que aceptará una conexión e imprimirá información de depuración en la ventana del terminal. Vea si puede reproducir el problema y luego examine lo que registró el servidor.

Si no puede desconectar el servidor ssh normal, puede ejecutar sshd en otro puerto: /path/to/sshd -p 42 -dejecuta una copia de sshd escuchando en el puerto 42. Especifique el mismo número de puerto cuando ejecute el cliente ssh: ssh -p 42 user@host. Si sus problemas se deben a un dispositivo de red que interfiere, esto puede comportarse de manera diferente a las conexiones al puerto 22.

información relacionada