(Y un día conocí a) Mosh, la evolución móvil de SSH

Gabolonte Blasfemus

moshEs increíble como uno de los antes y después de comenzar a laburar con *nix boxes es que, cuando te querés acordar, respirás la línea de comandos. No me refiero a que te los vas a saber todos de memoria, pero sí a que de repente vas a saber dónde estás más o menos parado y, en caso de que no te acuerdes qué deberías tipear, al menos saber cómo y en dónde buscarlo con confianza. Pero lo que sí se comienza a respirar casi con naturalidad es SSH. SSH para montar una unidad, para ver estadísticas del sistema, para correr scripts; SSH para todo.

No es para menos, es un protocolo muy seguro (si está bien implementado el cliente), podemos redireccionar infinitos puertos para usar túneles seguros y así llegar a cualquier servicio dentro de otra red (como VNC, uno de los primeros usos que todos le damos), y podemos tener tantas terminales abiertas como se nos antoje. Es casi de tereso pedirle más.

Pero SSH, igual, tiene unas fallitas. Incluso dicen, ojo, dicen, yo no tengo nada que ver, que hasta Telnet hace un par de cositas mejor, dejando de lado que usar Telnet es el equivalente en seguridad a usar justamente VNC sin SSH (todo viaja en texto plano). Pero hay una que hemos notado todos alguna vez, otros más, otros menos, y es hasta cierto punto esperable, porque asumimos que nos pasaría con cualquier otra sesión vía red: Con una conexión del ogt nos caemos y hay que volver a entrar todo el tiempo. El problema de caerse y volver a entrar, además de que si sucede muchas veces ya es molesto de por sí, es que cada vez que volvemos a conectar es como si abriéramos una nueva ventanita de terminal: Salvo por el historial de Bash, es empezar de cero. Si estábamos corriendo un proceso o script, el mismo fue interrumpido ni bien el servidor detectó la pérdida de conexión. Nada simpático si estamos copiando archivos, editando una configuración, o corriendo una máquina virtual por consola.

Y no es que SSH no se aguante un microcorte en la red; si el corte es de unos segundos y seguimos en la misma IP es posible que volvamos como si nada. El problema es con conexiones realmente crapulentas como por ejemplo, adivinen, la de cualquier compañia de telefonía celular, donde no sólo podemos a llegar a tener más cortes que tiempo de conexión, sino que además podemos llegar a tener varios cambios de IP en poco tiempo. Ahí no hay aguante que valga, y nuestra sesión SSH se va al joraca, junto con lo que veníamos haciendo. Existe una solución tradicional para eso que es screen, una maravilla en sí misma con tantos usos que se merece un post entero sólo para nombrarlos. Pero aún así screen no soluciona un pequeño detalle que también puede ayudar a terminar de volvernos locos en una conexión intermitente: El eco de los caracteres tipeados en SSH es remoto, eso quiere decir que para que veamos cada letra que pulsamos el caracter tiene que ir primero como pulsación hasta el servidor para luego volver y ser visto recién en nuestra pantalla. Nada más lindo que escribir con un lag de más de 2 segundos por cada letra que presionamos.

Esos son los pequeños detalles de SSH, y el que intenta solucionarlos es Mosh, nombre contracción de Mobile Shell, porque fue creado justamente con los dispositivos móviles en mente y sus conexiones inestables y cambiantes. Mosh existe desde hace un tiempo, pero recién ahora se lo comienza a ver dando vueltas por varios lados, tanto como para que este humilde servidor se percate del mismo.

¿Cuáles son las ventajas más importantes de Mosh por sobre SSH?

  1. El eco es local, o sea que aunque la conexión apeste todo el tiempo igual vemos lo que escribimos, y un algoritmo predictivo se ocupa de que la mayoría de las veces veamos lo que se supone deberíamos estar viendo, incluso mientras usamos aplicaciones como editores de texto.
  2. No se corta la sesión, ni al cambiar de IP, ni por tener quinchicientos mil cortes en la conexión, ni por suspender la notebook y abrirla en dos horas. Una vez iniciada, la sesión se mantiene, no importa las condiciones de la red, pudiendo siempre resumir luego lo que estábamos haciendo.
  3. Es más rápido que SSH, ya que toda la conexión se establece vía el protocolo UDP, siempre más rápido que TCP.

Esas fueron las ventajas que Mosh tiene sobre SSH, pero hay una ventaja que tiene en sí mismo: No es necesario configurarlo como servicio de la misma forma que deberíamos hacer con SSH o algún otro demonio, necesitando root para configurar el servicio; de hecho Mosh utiliza el servicio de SSH para conectarse al servidor remoto y ejecutarse en el mismo, pero con los derechos de la cuenta con la que iniciamos sesión, por lo que si ya tenemos SSH configurado y andando en realidad no necesitamos más que instalar Mosh sin siquiera tocar un sólo archivo de configuración. O sea que cuando ejecutamos el cliente de Mosh lo primero que hace es conectarse por SSH al servidor remoto, luego desde la sesión SSH ejecutar el servidor de Mosh en modo usuario con los parámetros que le hayamos dado, desconectarse de la sesión SSH y finalmente conectarse al servidor Mosh por UDP. Esta especie de retro-compatibilidad con SSH permite que podamos moshear contra servidores que tengamos definidos en .ssh/config por ejemplo, sin ningún problema. Pero esta ventaja presenta una desventaja que nos lleva a…

¿Contras? No está soportada la redirección de puertos, y tiene algo de sentido, ya que Mosh puede estar optimizado para conexiones muy inestables, pero seguramente los servicios que usemos a través de un túnel no (de todas formas está planeado a futuro implementar redirección de puertos para X11 y otros servicios específicos). El otro tema es que si para SSH sólo debíamos preocuparnos de tener abierto el puerto TCP en el que escucha el daemon SSH, ahora también deberemos contemplar un puerto extra para Mosh en UDP, aunque es algo un poco más complicado que eso. Si intentamos una conexión tan sólo corriendo mosh usuario@servidor vamos a tener dos problemas: Para SSH va a asumir el puerto por defecto (22), pero para Mosh el servidor va a asignar un puerto UDP que puede variar entre 60000 y 61000, que es el rango especificado para escucha de un servidor Mosh. Por supuesto, si mapeamos en nuestro NAT todo ese rango a un sólo equipo entonces sólo tendremos la posibilidad de tener configurado un único servidor Mosh por red. Hay que volverse selectivo y decirle al servidor Mosh que escuche por un puerto UDP específico elegido por nosotros, y para eso simplemente hace falta agregar el argumento -p y el número de puerto, por ejemplo:

$ mosh -p 60001 usuario@servidor

¿Y el puerto de SSH? ¿Qué pasa si lo tenemos en uno distinto al estándar? Para indicar parámetros que corresponden a la conexión SSH cuando se invoca a mosh debemos usar el argumento –ssh de la siguiente forma:

$ mosh -p 60001 --ssh="ssh -p 2222" usuario@servidor

Entonces así, no sólo estamos indicando que nuestra conexión por Mosh se hará a través del puerto UDP 60001, sino que la conexión SSH desde donde se ejecutará al servidor Mosh configurado para escuchar en dicho puerto se hará por el TCP 2222.

Otra opción, como mencionaba antes, es directamente aprovecharnos de los servidores que tengamos definidos en nuestro archivo .ssh/config:

$ mosh -p 60001 server_ssh_definido

En este caso le seguimos diciendo al cliente de Mosh que la conexión se hace por el puerto UDP 60001, pero todo el resto de la información la saca del archivo de configuración SSH en donde está definido el servidor correspondiente con el alias server_ssh_definido, donde figura su IP o nombre de host y su puerto SSH de escucha.

El problema de tener que definir el puerto extra para la conexión vía Mosh no sólo radica en tener que hacer un agujero más en los firewalls sino que, como (aún) no existe un equivalente del archivo de configuración de SSH para Mosh, siempre deberemos definir el puerto UDP en la línea de comandos, o usar un script a modo de alias. Existe una suerte de parche para esto llamado Moshy, otro proyecto open source al igual que Mosh, pero ahí ya debemos familiarizarnos con algo más.

Pero las deventajas son relmente pocas, y digamos que compramos. Ahora, ¿cómo lo conseguimos? En la última versión de Ubuntu o Linux Mint es fácil, basta apt-get como para todo:

$ sudo apt-get install mosh

Si la versión de Ubuntu o su derivativa en uso no es la más reciente tal vez sea necesario conseguir la última versión de Mosh desde sus repositorios PPA:

$ sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:keithw/mosh
$ sudo apt-get update
$ sudo apt-get install mosh

La buena noticia es que en la mayoría de las distros, al menos en las últimas versiones, figura en los repositorios oficiales para instalarlos directamente. Si tenemos algo un poco más viejo como por ejemplo un Debian Squeeze el tema se complica pero no es imposible sin algo de guía que nos indique las instalación de las dependencias pertinentes y la descarga y compilación del código fuente, aunque debermos procurarnos el link a la última versión nosotros mismos.

Seguramente Mosh puede llegar a ser un gran aliado en toda notebook víctima de redes Wi-Fi flojas y cambiantes o patéticos enlaces 3G, pero la verdadera razón de ser de esta evolución de SSH es la movilidad; no tendría sentido si no lo podemos usar en smarptones o tablets. En iOS está disponible a través de una única aplicación de pago, iSSH, y encima vía una compra in-app, pero al menos está. Como siempre en nuestro querido Androide el panorama está un poco mejor para quienes no deseamos pasar tarjeta por cada suspiro que damos, ya que tenemos dos opciones y las dos son, mayormente, gratuitas: JuiceSSH es la más atractiva, tiene decenas de funciones y, acorde a sus especificaciones, soporte oficial para Mosh; mediante una compra in-app se pueden adquirir varias funciones Pro, pero no son necesarias para conectarse ya mismo a un servidor Mosh. La segunda opción es una versión modificada del cliente SSH para Android Irssi ConnectBot, el cual a su vez es una mejora del formidable, confiable, pero estancado proyecto open source ConnectBot. Esta versión modificada se ofrece junto a su código fuente y es completamente gratuita, pero sus desventajas son que no está disponible en Google Play, y deberemos descargar e instalar el archivo APK desde la página de Daniel Drown, el creador del port. Tampoco podremos tener esta versión especial de Irssi ConnectBot junto a la original simultáneamente pero, fuera de eso, a mí personalmente fue la opción que más me gustó, principalmente por ofrecer los fuentes y por sus orígenes en ConnectBot.

Conexión usando Mosh desde Irssi ConnectBot

Conexión usando Mosh desde Irssi ConnectBot

Y sí, windoleros, la mala noticia es que aún no existe un cliente nativo de Windows para Mosh, y la única opción es usarlo con Cygwin. El enlace de descarga para este y otras plataformas lo podemos encontrar en mosh.mit.edu/#getting. Pero la buena es que hay un cliente de Mosh para Chrome, así que desde ahí podemos usarlo en cualquier OS de escritorio y por supuesto también Chromebooks.

Ahora la pregunta del millón centavo es: ¿Dejarías (o dejaste) de usar SSH diariamente para pasarte a Mosh? Yo no puedo decir que no me gustaría hacerlo, aunque lamentablemente algunas distribuciones específicas aún no lo incluyen en sus repositorios.


2 Responses to “(Y un día conocí a) Mosh, la evolución móvil de SSH”

  • Daniel P Z despachó:

    Wuau, que completicimo articulo sobre mosh, no lo conocia realmente, y ahora que as expuesto todas las ventanas de él, me gustaría probarlo algún tiempo, y si, es cierto, es muy molesto tener de volverse a conectar a cada rato por ssh x tener una conección mierd@ wifi,

    Muchas gracias por esta publicación.


    Usando Google Chrome Google Chrome 43.0.2318.0 en Windows Windows 7
  • Mauro despachó:

    Excelente nota, ya me lo instalo 😛


    Usando Mozilla Firefox Mozilla Firefox 42.0 en Windows Windows NT