Mosh

¿Quién escribió Mosh?

Mosh fue escrito por Keith Winstein, junto con Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister y John Hood.

P: ¿Por qué otro protocolo de terminal remota?

La latencia práctica en Internet va en aumento, con el incremento del bufferbloat y los sofisticados enlaces inalámbricos que optimizan el rendimiento frente al retraso. Y la itinerancia es más común que nunca, ahora que los portátiles y los dispositivos de mano han desplazado en gran medida a los ordenadores de sobremesa. SSH es genial, pero es frustrante cuando se quiere cambiar de dirección IP o se tiene un enlace con mucho retardo o una conexión dudosa.

Además, TELNET tenía algunas cosas buenas: un modo de eco local y una terminal virtual de red bien definida. Incluso hoy en día, SSH no soporta adecuadamente UTF-8 de extremo a extremo en un sistema POSIX.

P: ¿Son los principios mosh relevantes para otras aplicaciones de red?

Creemos que sí. Los principios de diseño que Mosh defiende son conservadores: advertir al usuario si el estado que se muestra no está actualizado, serializar y comprobar todas las transacciones para que, si no hay advertencias, el usuario sepa que todas las transacciones anteriores han tenido éxito, y manejar los eventos esperados (como la itinerancia de una red WiFi a otra) con gracia.

Estos no parecen demasiado controvertidos, pero las aplicaciones de lujo como Gmail-in-Chromium o en Android todavía se comportan atrozmente en conexiones dudosas o después de cambiar las direcciones IP. (¿Te ha pasado que Gmail deja un mensaje de correo electrónico en «Enviando…» durante diez horas mientras recupera alegremente nuevos correos y no indica ningún tipo de error? A nosotros también). Creemos que la aplicación de estos valores puede mejorar considerablemente muchas interfaces de usuario de la red.

P: Me aparece «mosh requiere una configuración regional UTF-8». ¿Cómo puedo arreglar esto?

Para diagnosticar el problema, ejecute locale en el terminal local, y ssh remotehost locale. Para utilizar Mosh, ambos lados de la conexión tendrán que mostrar una configuración regional UTF-8, como LC_CTYPE="en_US.UTF-8".

En muchos sistemas, SSH transferirá las variables de entorno relacionadas con la configuración regional, que luego serán heredadas por mosh-server. Si este mecanismo falla, Mosh (a partir de la versión 1.2) pasará las variables por sí mismo. Si ninguno de los dos mecanismos tiene éxito, puede hacer algo como

mosh remotehost --server="LANG=en_US.UTF-8 mosh-server"

Si en_US.UTF-8 no existe en el servidor remoto, puede sustituirlo por una configuración regional UTF-8 que sí exista. Es posible que también tenga que establecer LANG localmente en beneficio de mosh-client. Es posible que las máquinas locales y remotas necesiten diferentes nombres de configuración regional. Vea también este ticket de GitHub.

P: ¿Qué significa el mensaje «No se recibe nada del servidor en el puerto UDP 60003»?

Esto significa que mosh fue capaz de iniciar mosh-server con éxito en la máquina remota, pero el cliente no es capaz de comunicarse con el servidor. Esto generalmente significa que algún tipo de firewall está bloqueando los paquetes UDP entre el cliente y el servidor. Si tuvo que reenviar el puerto TCP 22 en un NAT para SSH, entonces tendrá que reenviar también los puertos UDP. Mosh utilizará el primer puerto UDP disponible, empezando por el 60001 y terminando en el 60999. Si sólo va a tener un pequeño puñado de sesiones simultáneas en un servidor, entonces puede reenviar un rango más pequeño de puertos (por ejemplo, 60000 a 60010).

Herramientas como netstat, netcat, socat y tcpdump pueden ser útiles para depurar problemas de red y de cortafuegos.

Este problema también puede ser el resultado de un error en glibc 2.22 que afecta a los programas que enlazan con protobuf y utempter y utilizan banderas agresivas de endurecimiento del compilador. (entrada del bugtracker de glibc, así como la entrada del bugtracker de Mosh.) El problema hace que mosh-server falle inmediatamente al iniciarse. Creemos que hemos solucionado este problema en Mosh 1.2.6, pero por favor informe de un error si encuentra lo contrario.

P: ¿Por qué insisten en UTF-8 en todas partes?

Realmente no somos fanáticos de UTF-8. Pero es mucho más fácil implementar correctamente un emulador de terminal que tratar de hacer lo correcto en una variedad de casos límite difíciles. (Esto es lo que intenta hacer GNU screen, y en nuestra experiencia conduce a algunas situaciones muy difíciles de depurar). Así que mosh simplemente no se iniciará hasta que el usuario tenga todo configurado para una ruta limpia de UTF-8. Puede ser molesto, pero también probablemente reduce la frustración en el camino. (Desafortunadamente un vt220 de 8 bits y un vt220 UTF-8 son tipos de terminal diferentes e incompatibles; el UTF-8 va debajo de la máquina de estado vt220.)

P: ¿Cómo puedo usar un puerto SSH diferente (no el 22)?

A partir de Mosh 1.2, puede pasar argumentos a ssh así:

mosh remotehost --ssh="ssh -p 2222"

O configurar un alias de host en ~/.ssh/config con una directiva Port. Mosh también lo respetará.

P: Estoy recibiendo ‘mosh-server not found’.

Por favor, asegúrese de que mosh está instalado en el cliente, y mosh (o al menos mosh-server) está instalado en el servidor al que está intentando conectarse. Además, se espera que el servidor esté disponible en el inicio de sesión por defecto de su servidor PATH, lo que no suele ser cierto en los servidores OS X y BSD, o si instala mosh-server en su directorio personal. En estos casos, por favor, vea las instrucciones de «Binario del servidor fuera de la ruta» en la sección Uso, más arriba.

P: SSH se autentifica usando tickets Kerberos, pero Mosh me pide una contraseña.

En algunas configuraciones, SSH canoniza el nombre de host antes de pasarlo al plugin GSSAPI de Kerberos. Esto se rompe para Mosh, porque la búsqueda inicial de DNS es realizada por el script envolvente de Mosh. Para evitarlo, invoque a Mosh como

mosh remotehost --ssh="ssh -o GSSAPITrustDns=no"

. En ese caso, probablemente sea mejor elegir un host específico del grupo de round-robin.

P: ¿Por qué el búfer de desplazamiento de mi terminal está incompleto?

Mosh sincroniza sólo el estado visible del terminal. Estamos siguiendo este problema; vea este problema y los otros que están enlazados desde allí. Por ahora, la solución es usar screen o tmux en el lado remoto.

P: ¿Cómo obtengo 256 colores?

Asegúrese de que está ejecutando Mosh en un terminal que se anuncia como capaz de 256 colores. (Esto generalmente significa que TERM será xterm-256color o screen-256color-bce.)

P: ¿Cómo escribo C-^, el carácter de escape por defecto de Mosh?

En los teclados con la disposición de los Estados Unidos, esto puede ser escrito como Ctrl-Shift-6, o a menudo como Ctrl-6 (esto depende de su sistema operativo y emulador de terminal). En los teclados no estadounidenses, a menudo es difícil encontrar la tecla correcta, y a veces no está disponible en absoluto. Si tu teclado tiene una tecla muerta con acento-circunflejo, no es probable que sea la tecla correcta. Sin embargo, Ctrl-6 a veces funciona. Si no puede escribir este carácter, tendrá que configurar la variable MOSH_ESCAPE_KEY; consulte la página man de Mosh para obtener más detalles.

P: ¿Cómo puedo hacer que el servidor limpie automáticamente las sesiones inactivas?

Por favor, vea las entradas para MOSH_SERVER_NETWORK_TMOUT y MOSH_SERVER_SIGNAL_TMOUT en la página man de mosh-server(1).

P: ¿Cuál es el historial de seguridad de Mosh hasta ahora?

Mosh 1.0 fue lanzado en marzo de 2012. A partir del lanzamiento de Mosh 1.3.2 en julio de 2017, por lo que los desarrolladores saben:

• En los últimos cuatro años, no se han reportado vulnerabilidades de seguridad de ningún tipo (mayores o menores) en Mosh.
• Nunca se ha informado de ninguna vulnerabilidad de seguridad importante en Mosh. Definimos las vulnerabilidades de seguridad importantes para incluir la escalada de privilegios, la ejecución remota de código, la denegación de servicio por parte de un tercero, etc.
• Dos problemas de denegación de servicio fueron descubiertos y corregidos en las versiones de 2012. Un problema permitía que un servidor mosh hiciera que el cliente mosh gastara un exceso de CPU (CVE-2012-2385, corregido en Mosh1.2.1, publicado en mayo de 2012). Otro problema permitía que el servidor-host hiciera que el mosh-cliente enviara datagramas UDP a una dirección incorrecta, frustrando su intento de conexión (corregido en Mosh 1.2.3, publicado en octubre de 2012).

P: ¿Cómo se compara la seguridad de Mosh con la de SSH?

Creemos que el diseño conservador de Mosh significa que su superficie de ataque se compara favorablemente con sistemas más complicados como OpenSSL y OpenSSH. El historial de Mosh lo ha confirmado hasta ahora. Sin embargo, en última instancia, sólo el tiempo dirá cuándo se descubre la primera vulnerabilidad de seguridad grave en Mosh, ya sea porque estaba allí todo el tiempo o porque se añadió inadvertidamente en el desarrollo. OpenSSH y OpenSSL han tenido más vulnerabilidades, pero también han sido publicados durante más tiempo y son más frecuentes.

En un aspecto concreto, el protocolo Mosh es más seguro que el de SSH: SSH se basa en TCP no autenticado para llevar el contenido del flujo seguro. Esto significa que un atacante puede terminar una conexión SSH con un solo segmento «RST» falso. Por el contrario, Mosh aplica su seguridad en una capa diferente (autenticando cada datagrama), por lo que un atacante no puede terminar una sesión Mosh a menos que el atacante pueda impedir continuamente que los paquetes lleguen al otro lado. Un atacante transitorio sólo puede causar una interrupción transitoria visible para el usuario; una vez que el atacante se vaya, Mosh reanudará la sesión.

Sin embargo, en el uso típico, Mosh se basa en SSH para intercambiar claves al comienzo de una sesión, por lo que Mosh heredará las debilidades de SSH, al menos en la medida en que afecten a la breve sesión de SSH que se utiliza para establecer una sesión de Mosh de larga duración.

P: ¿Se ve Mosh afectado por los ataques de 2018 contra el modo de cifrado OCB2?

No que sepamos-Mosh utiliza OCB3. Los autores del artículo escriben que el ataque no es aplicable a OCB3.

P: ¿Por qué Mosh utiliza AES-128 para una clave de sesión, y no AES-192 o AES-256?

• AES-128 es una longitud de clave más que adecuada para una clave de sesión.
• Las FAQ de OCB recomiendan AES-128.
• AES-128 es un poco más agradable y no está sujeto a los ataques de clave relacionada que afectan a AES-192 y AES-256. (Schneier: «el programa de claves para la versión de 256 bits es bastante malo -algo que señalamos en nuestro artículo de 2000- pero no se extiende a AES con una clave de 128 bits». Ver esta entrada del blog.)

P: ¿Funciona mosh con Amazon EC2?

Sí, funciona muy bien, pero recuerde abrir los puertos UDP 60000-61000 en el firewall de EC2.

P: ¿Cómo puedo saber si mosh está funcionando correctamente?

Después de ejecutar mosh user@server, si tiene éxito se le dejará caer en su shell de inicio de sesión en la máquina remota. Si quiere comprobar que se está utilizando mosh en lugar de ssh, intente escribir Ctrl-^ Ctrl-Z para suspender la sesión (con mosh 1.2.4 o posterior en el cliente). Ejecutando fg regresará entonces.

P: ¿Cuál es la diferencia entre mosh, mosh-client y mosh-server? ¿Cuál debo usar?

El comando mosh es un script de envoltura que está diseñado para ser la forma principal de utilizar mosh. En la mayoría de los casos, puedes simplemente reemplazar «ssh» por «mosh» en tu línea de comandos. Detrás de las escenas, la secuencia de comandos envolvente mosh SSH al servidor, iniciar mosh-server, y luego cerrar la conexión SSH. Luego iniciará el ejecutable mosh-client en el cliente, pasándole la información necesaria para que se conecte a la instancia mosh-server recién generada.

En el uso normal, mosh-client y mosh-server no necesitan ser ejecutados directamente.

P: ¿Cómo puedo ejecutar el cliente y el servidor Mosh por separado?

Si el script envolvente mosh no le funciona, puede intentar ejecutar los programas mosh-client y mosh-server por separado para formar una conexión. Esto puede ser una técnica de depuración útil.

1. Inicie sesión en el host remoto y ejecute mosh-server.

Dará una salida como:

$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQwmosh-server (mosh 1.1.3)Copyright 2012 Keith Winstein <[email protected]>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

2. En el host local, ejecute:

$ MOSH_KEY=key mosh-client remote-IP remote-PORT

donde «key» es la cadena de 22 bytes impresa por mosh-server (en este ejemplo, «4NeCCgvZFe2RnPgrcU1PQw»), «remote-PORT» es el número de puerto dado por el servidor (60004 en este caso), y «remote-IP» es la dirección IP del servidor. Puedes buscar la dirección IP del servidor con «host remotehost».

3. Si todo va bien, deberías tener una conexión Mosh que funcione. La información sobre dónde falla el proceso puede ayudarnos a depurar el motivo por el que Mosh no le funciona.

P: Con el servidor Mosh en FreeBSD u OS X, a veces tengo problemas extraños de color. ¿Qué ocurre?

Este error se ha corregido en Mosh 1.2. Gracias a Ed Schouten y Peter Jeremy por localizarlo.

P: ¿Cómo puedo contribuir a Mosh?

¡Damos la bienvenida a su contribución! Por favor, únase a nosotros en el canal #mosh en Freenode IRC, visítenos en GitHub, o envíe un correo electrónico a [email protected]. Para contribuir a nuestra base de código, por favor bifurca el repositorio en GitHub y abre una solicitud de extracción allí.

P: ¿Quién ayudó con mosh?

Estamos muy agradecidos por la ayuda y el apoyo de:

• Hari Balakrishnan, que aconsejó este trabajo y se le ocurrió el nombre.
• Paul Williams, cuyo diagrama de estado vt500 de ingeniería inversa es la base para el analizador Mosh.
• Los usuarios anónimos que contribuyeron con registros de sesión para afinar y medir el eco predictivo de Mosh.
• Nickolai Zeldovich por sus útiles comentarios sobre el documento de investigación de Mosh.
• Richard Stallman por su útil discusión sobre las capacidades del protocolo de edición local SUPDUP.
• Nelson Elhage
• Christine Spang
• Stefie Tellex
• Joseph Sokol-Margolis
• Waseem Daher
• Bill McCloskey
• Austin Roach
• Greg Hudson
• Karl Ramm
• Alexander Chernyakhovsky
• Peter Iannucci
• Evan Broder
• Neha Narula
• Katrina LaCurts
• Ramesh Chandra
• Peter Jeremy
• Ed Schouten
• Ryan Steinmetz
• Jay Freeman
• Dave Täht
• Larry Doolittle
• Daniel Drown
• Timo Juhani Lindfors
• Timo Sirainen
• Ira Cooper
• Felix Gröbert
• Luke Mewburn
• Anton Lundin
• Philipp Haselwarter
• Timo J. Rinne
• Barosl Lee
• Andrew Chin
• Louis Kruger
• Jérémie Courrèges-Anglas
• Pasi Sjöholm
• Richard Woodbury
• Igor Bukanov
• Geoffrey Thomas
• Steve Dignam
• HIGUCHI Yuta
• Baruch Siach