Las conexiones SSH se congelan con "Error de escritura: tubería rota"

12

Me estoy conectando a una caja CentOS 5.5 a través de SSH desde una máquina Ubuntu 11.04.

La conexión parece funcionar como se espera cuando está en uso activo (es decir, sin retraso ni pérdida), pero si se deja inactiva durante un tiempo, se congelará y dejará de responder. Finalmente, se devolverá el mensaje de error "Error de escritura: tubería rota" y volveré a la solicitud de mi máquina local.

¿Qué tipo de cosas puedo hacer para ayudar a depurar esto, descubrir qué está sucediendo y resolver esto? Como desarrollador, esto hace que mi vida sea un dolor tener que volver a conectarme constantemente.

ubuntu centos ssh timeout Stephen RC
fuente

Respuestas:

15

Parece que la configuración SSHD de la caja CentOS no está configurada para hacer el cliente KeepAlive.

Suelte estas dos líneas en su configuración de CentOS sshd (/ etc / ssh / sshd_config), reinícielo y ¡disfrute!

KeepAlive yes
ClientAliveInterval 60

Mientras lo hace, le recomiendo usar gnu screenpara mantener viva su sesión en el lado de CentOS.

yuriismaster
fuente
1
KeepAlive como se le cambió el nombre a TCPKeepAlive y se puede dejar en el valor predeterminado, que es sí. ClientAliveInterval debería ser suficiente. Ver man sshd_config.
ypid
9

La respuesta real es casi siempre que tiene un dispositivo NAT de algún tipo en la ruta, generalmente un firewall, cuyas tablas de estado tienen un tiempo de espera bastante agresivo. Debido a que deja su conexión ssh inactiva durante algunos períodos de tiempo, el dispositivo NAT "olvida" la asignación entre su dirección interna y el número de puerto de origen, y su dirección efímera externa y el número de puerto.

Cuando más tarde intente hacer algo en esa ventana ssh, se le asignará un nuevo par efímero de dirección / puerto, del cual el servidor ssh de destino no tiene conocimiento y no responde; más tarde, se alcanza un tiempo de espera local y su máquina local interrumpe la conexión.

La solución práctica para esto es hacer exactamente lo que yuriismaster sugiere: habilitar KeepAlives (que garantiza que el tráfico regular "haga cosquillas" a esa entrada de la tabla de estado) y usar screenen el lado remoto (para preservar el estado en caso de que las cosas se caigan). Solo publico esta respuesta porque preguntaste qué está sucediendo y qué hacer al respecto. Esperemos que esto aclare por qué las sugerencias de yuriismaster son buenas.

MadHatter
fuente
Eso tiene mucho sentido! Tenemos una configuración NAT con DMZ para este cuadro. Voy a probar la configuración de tiempo de espera y ver si eso funciona para mí. Gracias :)
Stephen RC
Estoy aceptando el tuyo ya que me ayudaste a entender las razones detrás del problema. Pero el crédito debe ir a @yuriismaster para la solución.
Stephen RC
Valorin: absolutamente, sí, y él fue el primero. Francamente, creo que merece la aceptación más que yo; pero es tu pregunta, así que debería ir como mejor te parezca. Gracias por los comentarios, de cualquier manera.
MadHatter