2010-01-20 23:33:01 +0000 2010-01-20 23:33:01 +0000
236
236

Manera de evitar el tiempo de espera de la conexión ssh y la congelación de la Terminal de GNOME

Cuando me conecto a través de ssh a ciertos servidores, se agota el tiempo y se “congela” la terminal (no acepta entrada, no se desconecta, no puede Ctrl-C para matar el proceso ssh ni nada).

Esto está en el gnome-terminal de Ubuntu, aunque parece que pausa la entrada/salida de la terminal, y no afecta al funcionamiento del propio software de la Terminal de GNOME. Así que es menos un error con gnome-terminal que una molesta inconsistencia con ssh.

Entonces, ¿hay alguna manera de prevenir/recuperar la terminal de las conexiones ssh que han terminado?

Respuestas (7)

259
259
259
2010-01-20 23:53:48 +0000

sshd (el servidor) cierra la conexión si no oye nada del cliente durante un tiempo. Puedes decirle a tu cliente que envíe una señal de vida al servidor de vez en cuando.

La configuración para esto está en el archivo ~/.ssh/config. Para enviar la señal cada cuatro minutos a remotehost, ponga lo siguiente en su ~/.ssh/config.

Host remotehost
  HostName remotehost.com
  ServerAliveInterval 240

Esto es lo que tengo en mi ~/.ssh/config.

Para habilitarlo para todos los hosts use:

Host *
  ServerAliveInterval 240

También asegúrese de ejecutar chmod 600 ~/.ssh/config, porque el archivo de configuración no debe ser legible por el mundo.

250
250
250
2010-01-20 23:44:01 +0000

Pulse Enter, ~, . uno tras otro para desconectarse de una sesión congelada.

La sección “ESCAPE CHARACTERS” en la página man de ssh explica los detalles subyacentes.

39
39
39
2012-07-03 01:28:14 +0000

Aunque esto no es una respuesta directa a tu pregunta, está muy relacionado con el problema que tienes. En lugar de tratar de mantener la conexión viva (todas las conexiones eventualmente mueren) puedes usar multiplexores de terminal, como screen y tmux que mantienen la sesión viva en el fondo incluso si tu terminal se desconecta.

Esencialmente, cuando te conectas al servidor SSH, ejecutas inmediatamente screen que creará y adjuntará una nueva sesión:

$ screen

Luego sigues adelante y haces tu trabajo con la shell como lo harías normalmente. Ahora, si la conexión se cae, cuando puedas volver a conectarte al servidor a través de SSH, obtendrás una lista de las sesiones actuales con:

$ screen -ls

Para volver a conectarse a una sesión:

$ screen -r <session>

donde <session> es el PID o un nombre de sesión. Se reconectará a su sesión y podrá continuar desde donde lo dejó.

Incluso puede separar la sesión y volver a conectarse desde casa para continuar desde el punto exacto en el que la dejó. Para desconectar la sesión se utiliza C-a seguido de C-d (es decir, Control + A y luego Control + D).

También hay un sencillo tutorial en línea .

Usar screen y tmux en servidores remotos se considera una mejor práctica y es altamente recomendable. Algunas personas llegan a tener screen como su shell de inicio de sesión por defecto, de modo que cuando se conectan inician inmediatamente una nueva sesión de screen.

12
12
12
2014-02-06 14:13:27 +0000

Pruebe a añadir -o ServerAliveInterval=30 a su cadena de conexión (30 significa 30 segundos y, por supuesto, puede ajustarse)

6
6
6
2016-02-12 22:45:27 +0000

También puede establecer un intervalo de tiempo de espera inactivo desde el lado del servidor SSH:

Archivo: /etc/ssh/ssh_config

Contenido:

ClientAliveInterval XX
ClientAliveCountMax YY

Esto funciona exactamente igual que la configuración del cliente, pero los paquetes nulos se envían desde el servidor, en lugar del cliente.

Extraído de: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html

2
2
2
2015-12-17 02:19:43 +0000

Para la gente que quiere evitar que el cliente se desconecte en primer lugar.

Podría intentar establecer ConnectTimeout 0 en el archivo de configuración. El valor 0 significa que la conexión se mantendrá viva indefinidamente a menos que se cierre.

su archivo de configuración (o ssh_config) podría tener este aspecto:

Host *
   ConnectTimeout 0
0
0
0
2020-01-24 11:55:41 +0000

En mi caso, el problema era el gran tamaño de la MTU. Puedes cambiar la MTU en el router si usas NAT, pero yo cambio la MTU en el servidor:

sudo /sbin/ifconfig eth0 mtu 1036
sudo /etc/init.d/networking restart

En Windows también puedes aumentar esta clave:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDataRetransmissions"=dword:00000010