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

15

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.

— gareth_bowles
fuente

6

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.

— Dave Drager
fuente

Gracias, Dave: la opción ServerAliveInterval funcionó muy bien.

— gareth_bowles

@Dave Escuché que algunos administradores de servidores desaprueban esta práctica, ya que puede ser (a) riesgo de seguridad o (b) carga injustificada del servidor. ¿Alguna de estas preocupaciones es válida, IYHO?

— Jonathan Day

Esta es una configuración en el punto final del cliente, por lo que, aunque se encuentre en un entorno hostil, esto podría aumentar la capacidad de que alguien lo engañe, es muy poco probable que afecte la seguridad de la conexión. Realmente tampoco puedo ver que esto cause una carga adicional.

— Dave Drager el

@Dave: Ingresé este comando pero obtuve el siguiente uso: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:] port] [-e escape_char] [-F configfile] [- I pkcs11] [-i archivo_de identidad] [-L [dirección_bind:] puerto: host: hostport] [-l nombre_inicio de sesión] [-m mac_spec] [-O ctl_cmd] [-o opción] [-p puerto] [-R [ bind_address:] port: host: hostport] [-S ctl_path] [-W host: port] [-w local_tun [: remote_tun]] [user @] hostname [command]

— user1050619

Esta solución también funcionó para PuTTY. La única opción que tuve que configurar fue en Conexión -> Segundos entre Keepalive: 15. La sesión SSH ha estado activa y bien durante más de 8 horas (Comcast), mientras que generalmente se desconectaba en <30 minutos.

— Dan Dascalescu

2

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?

— radio
fuente

Hice el TcpKeepAlive en el lado del cliente (en mi ~ / .ssh / config). Pensé que esto resolvería los problemas del firewall local, pero aún así agota el tiempo de espera.

— gareth_bowles

De forma predeterminada, está "activado" en el lado del servidor, pero verifique sshd_config para ver si no se ha deshabilitado.

— radio

Algunos cortafuegos desconectan una conexión TCP después de cierto tiempo INCLUSO si no están inactivos.

— TomOnTime

Algunos cortafuegos desconectan una conexión TCP después de cierto tiempo INCLUSO si no están inactivos. La forma de detectar esto es ver si te desconectas constantemente.

— TomOnTime

Aquí están las configuraciones que solía arreglar: TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3

— Matt Simmons

2

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.

— sysadmin1138
fuente

1

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.

— nik
fuente

0

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

— Dan Dascalescu
fuente