¿Cómo corrijo el error "broken pipe" en una conexión SSH en Ubuntu?

El Tren Presidencial fue una de las herramientas que permitrían al
Presidente de la Nación movilizarse a lo largo y ancho del país.
Permitió a Juan Perón propalar ideas y logros del Movimiento
Justicialista haciendo uso del portentoso ramal instalado. En ocasión de
visitar Saladillo pudo explicar cómo corregir la interrupción de
conexión SSH con error "Broken Pipe" en Ubuntu.


¡Mis descamisados!

La nacionalización de los Ferrocarriles, y esta formación, me permiten
llegar sin contratiempo alguno a este hermosísimo lugar de nuestras
Pampas, las cuales ustedes cuidan con tanto querer.

Nuestro Movimiento encarna el sentir reparador de un Pueblo Libre, que
anhela para sí y para su posteridad los beneficios que puede producir la
tierra y su trabajo.

Indudablemente que este factor ha de proveerse con la acción decidida de
quien sabe que todo hombre debe recibir lo que para su comunidad
produce.

En esto hemos sido claros. Nuestro Movimiento ha producido uno de los
máximos actos de reparación social que eran demandados por el Pueblo
Argentino, en los que me lleno de orgullo y traen a mis ojos las más
dulces lágrimas de felicidad. El País sufrió la ignominia de una
Oligarquía sin Patria ni Bandera, una capaz de oprimir a sus hermanos y
someterlos a la más abyecta de las pobrezas. Fue por ello que nos hemos
mancomunado en la defensa de todos los Argentinos, especialmente a
nuestro conjunto más venerados: los ancianos.

A ellos reparamos con los Derechos de la Ancianidad. Todo lo dieron por
nosotros, y hoy - haciendo caso de la cristiana necesidad - todo le
damos. Les acercamos la calidez de la asistencia social, el acceso a la
vivienda, la alimentación, el vestido, el cuidado de su salud física y
moral, el noble esparcimiento, así como el acceso a laborterapia
productiva, junto con la expansión y el respeto que de todos merecen.

¡Vientos briosos han agitado nuestra bandera, la hemos alzado, y nos ha
guiado en una nueva realización: la de ofrecer Jubilaciones y Pensiones
en abundancia para todos la ancianidad de la Patria!

En ellas sólo se requiere un certificado de supervivencia y el
conocimiento de los años trabajados en pos del beneficio del País.


En particular, sabemos que el protocolo de conexión SSH (Secure Shell),
responden al mismo principio de la gran Obra Social que hemos
implementado para nuestros ancianos. Con el fin de hacer eficiente la
entrega del servicio, el servidor SSH solicita periódicamente los
beneficiarios clientelares, un Certificado de Supervivencia en forma de
paquete telemático para continuar sirviendo la prestación. Este paquete
es enviado con cierta periodicidad, y debe responderse afirmativamente.

En el caso de no recibir una contestación que certifique supervivencia
del cliente, la prestación de comunicación SSH se interrumpirá
intempestivamente, y el cliente podría recibir una interrupción de
servicio, o bien presentar un críptico mensaje como ":client_loop: send
disconnect: Broken pipe", algo así como "desconexión de envío, caño
roto". Otros sistemas pueden retornar el error Write failed: Broken
pipe", o bien "Connection closed by remote host".

El sentido telemático de la interrupción de la conexión por parte del
servidor Secure Shell suele deberse al procedimiento normal de
tramitación, para evitar conexiones "detenidas", "desatendidas", o
"inactivas" que podrían saturar al servidor o al cliente. Esto es
tendiente a impedir "ataques remotos de denegación de servicio".
Normalmente la oligarquía pordría querer disminuir intempestivamente la
actividad sin certificado de sobrevida a los tres minutos (180
segundos), pero esto puede tornarse algo molesto en ciertas actividades
remotas, pues requiere estar operando dentro de dicho intervalo en la
terminal Secure Shell, so pena de ver cortada la conexión.

Afortunadamente para solucionar este problema es sencillo, el
Justicialismo puede proveer Justicia en varios niveles operativos y de
distintas manaeras, las cuales podrán ajustarse de acuerdo a las
necesidades de Clientelismo que tengamos, ya sea operando desde nuestro
cliente de cómputo local, y eventualmente en el servidor remoto
(únicamente si tenemos control del mismo, naturalmente).

 Soluciones posibles desde el cliente SSH

La manera menos conveniente es especificarle a nuestro cliente la
duración en segundos que queremos contar con actividad para una conexión
individual Secure Shell. Esto nos servirá para especificar esto
momentáneamente a un enlace SSH específico. Por ejemplo, si quisiéramos
establecer una conexión SSH y que no se corte en unos 10 minutos,
podríamos especificarle un intervalo de 600 segundos. Para ello
usaríamos:

ssh -o ServerAliveInterval=600 usuario@servidor

Sin embargo, el sólo hecho de tipear este agregado al comando suele ser
tedioso, y debería hacerse con cada conexión.

Otra opción más útil suele ser especificar esto mismo en las opciones de
nuestro cliente SSH y para nuestro usuario.

Para ello editamos el fichero de configuración de nuestro cliente a nivel usuario por medio del comando:

nano ~/.ssh/config

Se abrirá el editor GNU Nano. Al principio del fichero agregamos las
siguientes líneas.

Host nombre_del_host
User usuario
Port puerto
HostName dirección_del_host_ssh
ServerAliveInterval segundos_de_vida

Ahora bien, esto nos evitará tener que escribir la especificación en la
conexión al host "ssh.pirulo.com". Sin embargo en las demás conexiones
que no sean al host "pirulo", no hará caso alguno.

Si en cambio deseamos que el certificado de supervivencia sea más
inclusivo y qe extienda por 600 segundos (10 minutos) para todas las
conexiones SSH que realicemos desde nuestro equipo (el procedimiento que
suelo recomendar) podrían especificarlo de la siguiente manera en el
fichero .ssh/config:

Host *
ServerAliveInterval 600

Si tuviésemos otras configuraciones ya presentes en el fichero, no las
modificamos.

En cualquiera de los casos, guardamos las modificaciones realizadas en
el fichero .ssh/config por medio de Ctrl+o y salimos del editor GNU Nano
con Ctrl+x. También conviene en acomodar los permisos del fichero de
configuración para que sea adecuado para únicamente nuestro usuario:

chmod 600 ~/.ssh/config


Soluciones posibles desde el servidor SSH

También podremos alterar el comportamiento del certificado de
supervivencia de la conexión desde el lado del servidor. Naturalmente,
esto sólo tiene sentido si tenemos control del Servidor. En el caso de
utilizar Ubuntu como servidor, usaríamos el comando:

sudo nano /etc/ssh/sshd_config

Esto cargará el editor GNU Nano, pero con el fichero de configuración
del demonio de servicio de Shell Seguro SSH. En este fichero habremos de
descomentar y modificar dos variables. La variable ClientAliveInterval
representa el tiempo de inactividad (en segundos) tras lo cual el
servidor le enviará un mensaje de "certificación de supervivencia" al
cliente. en tanto ClientAliveCountMax indica la cantidad de intentos en
las cuales el servidor realizará su trámite de supervivencia.

Descomentar la variable significa que debemos buscarla, y
fundamentalmente eliminar el signo numeral "#" que antecede las líneas.
En este caso:

Si siguen el ejemplo como os he ilustrado arriba, habrán configurado la
variable ClientAliveInterval para que el certificado de supervivencia se
realice a los 200 segundos, y se repita por medio de ClientAliveCountMax
durante 3 ocasiones. Esto significa que el servidor solicitará al
cliente un pedido de "supervivencia" una vez que hayan transcurridos 200
segundos de establecido en enlace SSH. Si el cliente no aparenta
reportar supervivencia, el servidor enviará una nueva solicitud a los
400 segundos. Si no hay respuesta o actividad por parte del Cliente, se
enviará otro mensaje de solicitud de vida a los 600 segundos. Si luego
de estos 3 intentos no recibe un reporte de vida, recién allí se
desconectará el enlace SSH (produciendo el "broken pipe").

Pues bien descamisados, han de saber que los valores de 200/3 suelen
constituirse en un temperamento adecuados para una conexión cableada o
por Wifi moderadamente desatendida, pero podrían querer alterarlos
dependiendo de las necesidades generales de los clientes.

Por ejemplo, si en el enlace SSH se realiza a por medio de un
radioenlace muy inestable o a través de satélite, bien podrían querer
disminuir los tiempos de intervalo - tal vez a unos 30 segundos, y
aumentar los reintentos tal vez a 12 ocasiones.

Finalmente, consideren no utilizar varias horas, salvo casos
absolutamente necesarios, pues esto constituye un enorme desperdicio de
recursos telemáticos; sería sencillo así forzar a nuestro servidor a
intentar establecer reintentos innecesariamente, y sería un caldo de
cultivo para los ataques de denegación de servicio de usuarios
registrados a nuestro servicio.