26 november 2022
¿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.
Editamos el fichero de configuración de nuestro cliente a nivel usuario. Para ello usamos:
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.