Linux SSH Timeout [cerrado]


10

He estado luchando con un par de tiempos de espera del sistema después de X minutos de inactividad y no estoy seguro de cómo solucionarlo.

Tengo una caja CentOS en mi oficina. Connect to SSH no puede tocarlo durante 2 horas y sigue vivo cuando ejecuto algo.

Sin embargo, conéctese a esa misma caja en casa, y a veces se agota el tiempo de espera después de un par de segundos, a veces después de un par de minutos.

Creo que es mi conexión a Internet, sin embargo, si estoy usando activamente la caja, permanecerá conectada.

Sin embargo, si dejo de escribir algo en Google, se mostrará un mensaje desconectado y tendré que volver a conectarme.

¿Algo que pueda verificar para ver qué está pasando?


44
La documentación para su cliente (sin nombre).
user9517

Respuestas:


14

Lo primero que debe considerar es configurar ServerAliveInterval. Esto debe establecerse en su estación de trabajo.

En clientes Linux u OSX, puede crear un archivo de configuración para su usuario en ~ / .ssh / config en su estación de trabajo. Agregue la siguiente directiva. En mi caso, quiero que afecte a todos los hosts, así que lo puse en Host *.

Host *
    ServerAliveInterval 60

Esto enviará una instrucción noop cada 60 segundos para mantener la conexión abierta. Es posible que desee ajustar el valor para satisfacer sus necesidades.

En el lado del servidor, asegúrese de que TCPKeepAlive esté configurado en yes.

grep TCPKeepAlive /etc/ssh/sshd_config
TCPKeepAlive yes

Si está en Windows, deberá hacer referencia a la documentación de su cliente.


11

Linux no expira las conexiones SSH inactivas. Puede dejar una conexión SSH abierta indefinidamente, y siempre que ninguno de los puntos finales se reinicie u obtenga una nueva dirección IP, la conexión seguirá funcionando cuando acceda a ella después de un largo tiempo de inactividad.

Sin embargo, si hay middleboxes con estado (NAT, firewall, etc.), es probable que se agoten las conexiones inactivas. El resultado de eso es que, aunque la conexión está activa en ambos extremos, los dos puntos finales ya no pueden comunicarse porque el middlebox se niega a reenviar cualquier paquete hasta que el cliente SSH abra una nueva conexión.

Si conoce el tiempo de espera del middlebox, puede solucionar el problema configurando ClientAliveIntervalen /etc/ssh/sshd_configel servidor o ServerAliveIntervalen ~/.ssh/configel cliente. Para una detección óptima de conexiones rotas, es recomendable habilitar ambas configuraciones. Esto también detectará conexiones rotas cuando cualquiera de los puntos finales se haya reiniciado o haya obtenido una nueva dirección IP.

Como indica que el tiempo de espera a veces parece ser tan bajo como unos pocos segundos, esto podría no ser suficiente para resolver su problema. Un tiempo de espera aparente muy bajo puede ser causado por un CGN sobrecargado o mal configurado. Debe inspeccionar el tráfico en varios puntos de la ruta de comunicación para determinar si un CGN es responsable de las fallas.

Si resulta que las fallas son causadas por su ISP al hacer algo tonto, como las conexiones de equilibrio de carga a través de múltiples CGN que no comparten el estado de conexión, no puede solucionar el problema usted mismo simplemente ajustando su configuración SSH.

Si está atascado con un ISP con un CGN poco confiable que se niegan a arreglar, las únicas opciones restantes que conozco son actualizar el cliente y el servidor a las versiones de kernel con soporte MPTCP o usar una solución de túnel diseñada para tolerar espontánea cambios en las asignaciones de puertos en el NAT.

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.