3 alternatives à SSH pour les connexions instables

Mosh, Eternal Terminal et autossh résolvent la même défaillance de trois manières différentes : Mosh synchronise l’état du terminal via UDP et vous suit à travers les changements d’adresse IP, Eternal Terminal rétablit la même session via TCP, et autossh relance SSH automatiquement mais démarre une nouvelle session à chaque fois.

Si vous avez déjà vu un déploiement se figer en plein milieu parce que votre train entrait dans un tunnel, vous connaissez la suite : le terminal se bloque, vous attendez en espérant, et une minute plus tard vous vous retrouvez face à client_loop: send disconnect. Le Wi-Fi d’un café, un partage de connexion depuis un téléphone et un VPN capricieux produisent tous le même effet sur une session. La question n’est pas de savoir s’il faut remplacer SSH classique pour le travail interactif, mais lequel de ces trois outils correspond à votre réseau et à votre niveau d’accès au serveur. Cet article les compare selon un seul axe : ce qui arrive concrètement à votre session lorsque le lien tombe.

Que se casse-t-il quand le lien tombe ?

Une session SSH vit à l’intérieur d’une unique connexion TCP liée à l’adresse IP de votre client : lorsque le réseau tombe ou que l’adresse change, la connexion meurt et emporte avec elle le shell distant. TCP identifie une connexion par le quadruplet adresse et port source, adresse et port destination ; une nouvelle IP issue d’un nouveau réseau Wi-Fi signifie un nouveau quadruplet dont le serveur n’a jamais entendu parler. Dès que les keepalives échouent ou que la socket renvoie une erreur, sshd supprime le shell et tous les processus en avant-plan qu’il contient. Les trois outils ci-dessous s’attaquent chacun à un maillon différent de cette chaîne.

Mosh : synchronisation d’état via UDP

Comportement en cas de défaillance

Mosh remplace le modèle du flux d’octets par une synchronisation d’état : le client et le serveur conservent chacun un instantané de l’écran, et le State Synchronization Protocol de Mosh les fait converger via des datagrammes UDP chiffrés. Comme le serveur cible simplement l’adresse source du dernier paquet authentifié, l’itinérance à travers les changements d’IP est automatique : mettez le portable en veille, changez de réseau, et la session reprend sans aucune étape de reconnexion. L’écho local prédictif affiche vos frappes immédiatement au lieu d’attendre l’aller-retour vers le serveur.

Prérequis

Mosh nécessite le binaire mosh-server sur la machine distante (aucun droit superutilisateur ni démon permanent : les deux moitiés s’exécutent sous votre identité et s’arrêtent avec la session), ainsi qu’une accessibilité UDP. Mosh s’authentifie via une connexion SSH classique, puis utilise par défaut un port UDP dans la plage 60000 à 61000 (le premier port disponible à partir de 60001), que les pare-feux doivent autoriser. Il transmet les options au ssh sous-jacent :

mosh --ssh="ssh -i ~/.ssh/other_key" user@host

Ses limites

Si l’UDP est bloqué, Mosh ne fonctionne tout simplement pas : il n’existe aucun repli sur TCP. Mosh ne synchronise par ailleurs que les caractères actuellement affichés à l’écran, si bien que votre historique de défilement disparaît ; la FAQ du projet elle-même vous renvoie vers screen ou tmux côté distant. La comparaison des deux outils publiée par Eternal Terminal ajoute que Mosh ne peut pas piloter le mode contrôle de tmux (tmux -CC), ce qui importe aux utilisateurs d’iTerm2. La version la plus récente sur la page des releases du projet est la 1.4.0, datée d’octobre 2022.

Eternal Terminal : la même session via TCP

Comportement en cas de défaillance

Eternal Terminal reprend la connexion via du TCP ordinaire sans détruire ce que vous étiez en train de faire, session tmux en cours comprise : une coupure vous coûte donc une pause plutôt que votre travail. Comme il ne quitte jamais TCP, il fonctionne précisément sur les réseaux qui excluent Mosh : les pare-feux d’entreprise qui rejettent l’UDP et les chemins qui forcent le trafic à passer par un proxy TCP.

Prérequis

Eternal Terminal nécessite un démon côté serveur. Le README du projet pose deux prérequis : ssh assure la négociation et le chiffrement, donc ssh user@hostname doit fonctionner avant qu’ET ne le fasse, et le côté serveur écoute sur le port TCP 2022 sauf si vous le modifiez. Installation avec brew install et sur macOS, ou sur Ubuntu :

sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install et

Vérifiez le démon avec systemctl status et.

Ses limites

Une reconnexion via TCP signifie aucune magie d’itinérance et aucun écho local : sur un lien à forte latence, la saisie donne toujours la même sensation qu’avec SSH. Et comme il exige un démon installé en root et un port ouvert, il est hors jeu sur les machines où vous ne pouvez pas installer de logiciels.

autossh : relance automatique, nouvelle session

Comportement en cas de défaillance

autossh encapsule ssh et surveille le processus qu’il a lancé, en démarrant un remplaçant dès que ce processus se termine ou devient silencieux. Chaque reconnexion est une toute nouvelle session SSH : sans multiplexeur sur le serveur, ce que vous exécutiez a disparu quand le lien revient.

Prérequis

autossh ne nécessite rien sur le serveur au-delà d’un sshd en fonctionnement, ce qui en fait la seule option des trois sur les machines où vous ne pouvez pas installer de logiciels. Installation côté client :

sudo apt install autossh   # Debian/Ubuntu
sudo dnf install autossh   # Fedora/RHEL family (may need EPEL)
brew install autossh       # macOS

Ses limites

Il restaure la connexion, pas la session. Il dépend également du fait que ssh détecte la défaillance : la page de manuel suggère ServerAliveInterval et ServerAliveCountMax afin que le client abandonne rapidement une fois le lien mort.

tmux ou Zellij par-dessus

tmux et Zellij ne remplacent aucun de ces outils : ils maintiennent vos processus en vie sur le serveur, tandis que Mosh, Eternal Terminal et autossh maintiennent votre chemin d’accès au serveur, et les deux couches se combinent. Zellij est un multiplexeur de terminal qui gère les sessions, les panneaux et les onglets, et se superpose à une connexion distante de la même manière que tmux.

autossh associé à tmux constitue la configuration viable minimale, car elle rattache une session persistante à chaque relance :

autossh -M 0 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
  -t user@host "tmux new -A -s main"

-M 0 désactive le port de monitoring d’autossh, qui s’appuie alors sur la sortie de ssh elle-même, et tmux new -A -s main s’attache à (ou crée) la session main à chaque fois. Cet appariement profite aussi aux autres outils : tmux fournit l’historique de défilement qui manque à Mosh, et Eternal Terminal fait explicitement traverser les coupures à une session tmux.

Comment choisir parmi ces alternatives à SSH ?

Posez-vous trois questions dans l’ordre. L’UDP est-il bloqué entre vous et le serveur ? Si oui, Mosh est écarté ; Eternal Terminal est le choix résilient. Pouvez-vous installer quoi que ce soit sur le serveur ? Si non, autossh plus tmux est votre seule option. Sinon, choisissez selon vos préférences : Mosh pour l’itinérance et l’écho instantané sur les liens de mauvaise qualité, Eternal Terminal si vous avez besoin d’un véritable historique de défilement ou de tmux -CC.

C’est le mode de défaillance que vous ne pouvez pas tolérer qui détermine l’outil. Essayez d’abord Mosh sur un réseau ouvert, gardez Eternal Terminal pour les réseaux verrouillés, et placez dès aujourd’hui autossh -M 0 avec une session tmux nommée dans un alias shell ; cela améliore chaque machine à laquelle vous pouvez déjà accéder en ssh.

FAQ

Mosh fonctionne-t-il à travers un hôte de rebond ou un bastion SSH ?

Non. Mosh ne gère pas nativement les [tunnels SSH ni les hôtes bastions](https://docs.blink.sh/advanced/advanced-mosh). Un hôte de rebond peut porter la connexion SSH initiale, mais le trafic UDP chiffré doit ensuite atteindre directement la machine cible, ce qu'un serveur de rebond seul ne vous permet pas. Sur les réseaux accessibles uniquement via bastion, autossh fonctionne sans modification puisqu'il exécute un ssh ordinaire, qui prend en charge ProxyJump.

Mosh est-il aussi sûr que SSH classique ?

La connexion s'effectue toujours via SSH. Ensuite, Mosh chiffre et authentifie chaque datagramme UDP avec [AES-128 en mode OCB3](https://mosh.org/), un schéma de chiffrement authentifié. SSH n'est utilisé que pour échanger les clés au démarrage : une faiblesse de SSH toucherait donc cette brève étape d'initialisation plutôt que la session Mosh de longue durée. Vos clés SSH existantes et la vérification d'hôte s'appliquent sans changement.

autossh peut-il maintenir en vie des redirections de port SSH, et pas seulement des shells interactifs ?

Oui, les tunnels persistants comptent parmi les usages les plus courants d'autossh. Lancez-le avec -N pour qu'aucune commande distante ne s'exécute, -M 0 pour désactiver le port de monitoring, et vos habituelles options de redirection -L ou -R ; l'exemple fourni par la page de manuel combine lui-même -f -M 0 -N avec ServerAliveInterval et ServerAliveCountMax. Un tunnel ne conserve aucun état de shell, la limitation liée à la nouvelle session ne s'applique donc pas : autossh se contente de rétablir la redirection.