3 alternativas a SSH para conexiones inestables
Compara Mosh, Eternal Terminal y autossh para conexiones SSH inestables: UDP, reconexión TCP, requisitos del servidor y uso con tmux.
Mosh, Eternal Terminal y autossh resuelven el mismo fallo de tres maneras distintas: Mosh sincroniza el estado del terminal sobre UDP y te sigue a través de los cambios de IP, Eternal Terminal reconecta la misma sesión sobre TCP, y autossh reinicia SSH automáticamente pero abre una sesión nueva cada vez.
Si alguna vez has visto congelarse un deploy a mitad de camino porque tu tren entró en un túnel, ya sabes cómo sigue la historia: el terminal se bloquea, te quedas ahí esperando y, un minuto después, estás mirando fijamente un client_loop: send disconnect. El Wi-Fi de una cafetería, un móvil compartiendo datos y una VPN inestable le hacen exactamente lo mismo a una sesión. La cuestión no es si conviene sustituir el SSH tradicional para el trabajo interactivo, sino cuál de estas tres herramientas encaja con tu red y con tu nivel de acceso al servidor. Este artículo las compara sobre un único eje: qué le ocurre realmente a tu sesión cuando el enlace falla.
Puntos clave
- Mosh sincroniza el estado del terminal sobre UDP, Eternal Terminal reconecta la misma sesión sobre TCP y autossh reinicia SSH con una sesión nueva cada vez.
- Que UDP esté bloqueado o no entre tú y el servidor es el factor decisivo entre Mosh y Eternal Terminal.
- autossh es enteramente del lado del cliente y no necesita nada en el servidor más allá de sshd, pero cada reconexión aterriza en una shell nueva, así que necesita tmux o Zellij para resultar útil.
- tmux y Zellij se superponen a las tres herramientas; mantienen vivos los procesos en el servidor mientras estas herramientas mantienen vivo tu camino hacia el servidor.
¿Qué se rompe cuando cae el enlace?
Una sesión SSH vive dentro de una única conexión TCP ligada a la dirección IP de tu cliente, de modo que cuando la red se cae o la dirección cambia, la conexión muere y se lleva consigo la shell remota. TCP identifica una conexión mediante la cuádrupla de dirección y puerto de origen y destino; una IP nueva procedente de una red Wi-Fi nueva significa una cuádrupla nueva de la que el servidor jamás ha oído hablar. En cuanto fallan los keepalives o el socket da error, sshd elimina la shell y todos los procesos en primer plano que contiene. Las tres herramientas que siguen atacan cada una un eslabón distinto de esa cadena.
Mosh: sincronización de estado sobre UDP
Qué hace ante un fallo
Mosh sustituye el modelo de flujo de bytes por la sincronización de estado: cliente y servidor mantienen cada uno una instantánea de la pantalla, y el State Synchronization Protocol de Mosh las hace converger mediante datagramas UDP cifrados. Como el servidor simplemente apunta a la dirección de origen del último paquete autenticado, el roaming a través de cambios de IP es automático: suspende el portátil, cambia de red y la sesión se reanuda sin ningún paso de reconexión. El eco local predictivo muestra tus pulsaciones de inmediato, en lugar de esperar la ida y vuelta hasta el servidor.
Qué requiere
Mosh requiere el binario mosh-server en la máquina remota (sin privilegios de superusuario y sin ningún demonio de larga duración: ambas mitades se ejecutan con tu usuario y se detienen cuando termina la sesión), además de alcanzabilidad por UDP. Mosh se autentica mediante un login SSH normal y después usa, por defecto, un puerto UDP en el rango de 60000 a 61000 (el primer puerto disponible a partir del 60001), que los firewalls deben permitir. Pasa las opciones al ssh subyacente:
mosh --ssh="ssh -i ~/.ssh/other_key" user@hostDónde se queda corto
Si UDP está bloqueado, Mosh no funciona en absoluto; no hay fallback a TCP. Mosh además solo mantiene sincronizados los caracteres actualmente en pantalla, así que tu scrollback desaparece, y las propias FAQ del proyecto te remiten a screen o tmux en el extremo remoto. La comparativa de ambas herramientas de Eternal Terminal añade que Mosh no puede manejar el modo de control de tmux (tmux -CC), algo relevante para los usuarios de iTerm2. La versión más reciente en la página de releases del proyecto es la 1.4.0, de octubre de 2022.
Eternal Terminal: la misma sesión sobre TCP
Qué hace ante un fallo
Eternal Terminal retoma la conexión sobre TCP ordinario sin desmontar lo que estabas haciendo, incluida una sesión de tmux en ejecución, de modo que una caída te cuesta una pausa en lugar de tu trabajo. Como nunca abandona TCP, funciona precisamente en las redes que descartan a Mosh: firewalls corporativos que descartan UDP y rutas que fuerzan el tráfico a través de un proxy TCP.
Qué requiere
Eternal Terminal requiere un demonio del lado del servidor. El README del proyecto establece dos prerrequisitos: ssh se encarga del handshake y del cifrado, así que ssh user@hostname tiene que funcionar antes de que ET lo haga, y el lado del servidor escucha en el puerto TCP 2022 salvo que lo cambies. Instálalo con brew install et en macOS, o en Ubuntu:
sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install etComprueba el demonio con systemctl status et.
Dónde se queda corto
Reconectar sobre TCP significa que no hay magia de roaming ni eco local: en un enlace con alta latencia, teclear sigue sintiéndose como SSH. Y como necesita un demonio instalado con root y un puerto abierto, queda descartado en máquinas donde no puedas instalar software.
autossh: reinicio automático, sesión nueva
Qué hace ante un fallo
autossh envuelve a ssh y vigila el proceso que ha lanzado, arrancando un sustituto cada vez que ese proceso termina o se queda mudo. Cada reconexión es una sesión SSH completamente nueva, así que sin un multiplexor en el servidor, lo que estuvieras ejecutando habrá desaparecido cuando el enlace vuelva.
Qué requiere
autossh no requiere nada en el servidor más allá de un sshd en ejecución, lo que lo convierte en la única opción de las tres en máquinas donde no puedes instalar software. Instalación en el cliente:
sudo apt install autossh # Debian/Ubuntu
sudo dnf install autossh # Fedora/RHEL family (may need EPEL)
brew install autossh # macOSDónde se queda corto
Restaura la conexión, no la sesión. También depende de que ssh detecte el fallo: la página del manual sugiere ServerAliveInterval y ServerAliveCountMax para que el cliente se rinda rápido en cuanto el enlace esté muerto.
tmux o Zellij por encima
tmux y Zellij no sustituyen a ninguna de estas herramientas: mantienen vivos tus procesos en el servidor, mientras que Mosh, Eternal Terminal y autossh mantienen vivo tu camino hacia el servidor, y ambas capas se combinan. Zellij es un multiplexor de terminal que gestiona sesiones, paneles y pestañas, y se superpone a una conexión remota igual que lo hace tmux.
autossh con tmux es la configuración mínima viable, porque vuelve a conectar a una sesión persistente en cada reinicio:
autossh -M 0 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
-t user@host "tmux new -A -s main"-M 0 desactiva el puerto de monitorización de autossh, de modo que este se apoya en la propia salida de ssh, y tmux new -A -s main se conecta a (o crea) la sesión main cada vez. El emparejamiento también ayuda a las demás: tmux aporta el scrollback del que carece Mosh, y Eternal Terminal mantiene explícitamente una sesión de tmux a través de las caídas.
¿Cómo elegir entre estas alternativas a SSH?
Hazte tres preguntas en orden. ¿Está bloqueado UDP entre tú y el servidor? Si es así, Mosh queda descartado; Eternal Terminal es la opción resiliente. ¿Puedes instalar algo en el servidor? Si no, autossh con tmux es tu única jugada. Por lo demás, elige por preferencia: Mosh para roaming y eco instantáneo en enlaces malos, Eternal Terminal si necesitas scrollback real o tmux -CC.
| Mosh | Eternal Terminal | autossh | |
|---|---|---|---|
| Modelo de recuperación | Sincronización de estado sobre UDP, hace roaming entre IPs | Reconecta la misma sesión sobre TCP | Reinicia ssh, sesión nueva |
| Necesidades en el servidor | Binario mosh-server, UDP abierto | Demonio con root, puerto TCP 2022 | Solo sshd |
| Limitación principal | Sin UDP, sin sesión | Sin eco local | Sesión perdida sin tmux |
El modo de fallo que no puedes tolerar es el que elige la herramienta. Prueba Mosh primero en una red abierta, reserva Eternal Terminal para las restringidas y añade hoy mismo autossh -M 0 con una sesión de tmux con nombre a un alias de shell; mejora todas las máquinas a las que ya puedes acceder por ssh.
Preguntas frecuentes
¿Funciona Mosh a través de un jump host o bastión SSH?
No. Mosh no tiene ningún manejo integrado de [túneles SSH ni hosts bastión](https://docs.blink.sh/advanced/advanced-mosh). Un jump host puede transportar el login SSH inicial, pero después el tráfico UDP cifrado tiene que llegar directamente a la máquina destino, algo que un jump server por sí solo no te ofrece. En redes con acceso exclusivo por bastión, autossh funciona sin cambios porque ejecuta ssh ordinario, que soporta ProxyJump.
¿Es Mosh tan seguro como SSH a secas?
El login sigue ejecutándose sobre SSH. A partir de ahí, Mosh cifra y autentica cada datagrama UDP con [AES-128 en modo OCB3](https://mosh.org/), un esquema de cifrado autenticado. SSH solo se usa para intercambiar las claves al principio, así que una debilidad de SSH afectaría a ese breve paso de configuración y no a la sesión Mosh de larga duración. Tus claves SSH existentes y la verificación de host se aplican sin cambios.
¿Puede autossh mantener vivos los port forwards de SSH, y no solo las shells interactivas?
Sí, los túneles persistentes son uno de los usos más habituales de autossh. Ejecútalo con -N para que no se ejecute ningún comando remoto, -M 0 para desactivar el puerto de monitorización y tus flags habituales de reenvío -L o -R; el propio ejemplo de la página del manual combina -f -M 0 -N con ServerAliveInterval y ServerAliveCountMax. Un túnel no mantiene estado de shell, así que la limitación de la sesión nueva no se aplica: autossh simplemente restablece el reenvío.
