¿Por qué mi tiempo de espera ssh varía con la ubicación de la red?

Cuando me envían a uno de nuestros servidores de oficina (que ejecutan Fedora 10) desde casa, mi sesión se agota después de un período de actividad bastante corto (aproximadamente 5 minutos). He intentado usar TcpKeepAliveen el lado del cliente, sin ningún efecto.

Lo que no entiendo es que si estoy en la oficina de la LAN de la empresa, puedo dejar una sesión inactiva todo el día sin que se agote el tiempo, por lo que el comportamiento parece depender de mi ubicación.

¿Alguna idea de por qué sucede esto y cómo evitar los tiempos de espera cuando no estoy en la LAN? Estoy usando el cliente Terminal en Mac OSX si eso ayuda.

ACTUALIZACIÓN : la sugerencia de Dave Drager de usar el ServerAliveIntervalconjunto a no cero TcpKeepAlive=nofuncionó para mí. En cuanto a algunas de las otras respuestas, la ClientAliveconfiguración ... no es aceptada por el cliente SSH de Mac OSX.

Hay una buena crítica sobre este problema aquí .

Ellos recomiendan:

ssh -o TCPKeepAlive=yes

o:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

Sin embargo, tengo un problema en mi sitio de trabajo en el que me desconecto de las sesiones, donde en casa están bien. Creo que mi firewall (SonicWall) puede estar fallando con TCPKeepAlive, tal vez debido a NAT.

Afortunadamente, mi cliente SSH, SecureCRT, tiene una opción para un protocolo "NO-OP", que creo que básicamente envía un comando que no hace nada al servidor. Al habilitar esto manualmente, puedo permanecer conectado. No estoy seguro de qué tiene el cliente terminal MacOSX que sea similar a eso. Hay una escritura sobre cómo implementar "NO-OP" en la línea de comandos.

Finalmente, es posible que desee utilizar Wireshark u otro sniffer para ver su conexión TCP real y descubrir qué está sucediendo con ella. Esa sería la forma final de ver por qué todavía se desconecta ocasionalmente.

Esto probablemente se deba a que cuando se conecta desde su casa, pasa a través de un firewall que cierra la sesión TCP después de un corto período de tiempo. Pero TcpKeepAlive debería evitar esto. ¿Habilitó TcpKeepAlive en el lado del cliente o en el lado del servidor?

Recibo esto todo el tiempo en mi conexión de Comcast. El problema es que el intervalo de mantenimiento de su cliente SSH es demasiado largo para el tiempo de espera configurado en su ruta de red. Si está en Linux, puede modificar los valores ServerAliveIntervaly ServerAliveCounterpara que sean inferiores a sus valores predeterminados. Este valor se establece en segundos. El archivo de configuración de todo el sistema se encuentra (generalmente) en /etc/ssh/ssh_config. Establecer esos dos Y TcpKeepAlivedebería ayudar a mantener su conexión.

Como dice radius, algunos firewalls con estado completo 'olvidan' una conexión después de cierto tiempo (generalmente configurable) y no permitirán más comunicación para la conexión; esperan que la conexión comience con un TCP SYN (me refiero a su comunicación SSH aquí).

Hay otra posibilidad La ruta de red entre su hogar y oficina puede tener pérdidas (del tipo de paquete). Cuando intenta escribir en el cliente SSH, si su enlace se ha estancado por un tiempo, el cliente podría darse por vencido y fallar.

La configuración de Keepalive en el cliente manejará el primer caso aquí, pero no puede ayudar en el segundo caso. El firewall generalmente estaría en el perímetro de su oficina y, por lo tanto, podría ser configurable. Eso también ayudaría en el primer punto.

Para verificar si tiene pérdidas de enlace intermitentes, puede mantener un 'ping' activo en segundo plano desde su máquina cliente.

También puede agregar las configuraciones sugeridas por otros como predeterminadas en su ~/.ssh/configarchivo, para que no tenga que pasarlas sshcada vez que inicie una conexión:

nano ~/.ssh/config y añadir:

TCPKeepAlive=no
ServerAliveInterval=15