Ports UDP de Mosh 60000-61000 : règles ufw et exemples mosh -p

Mosh a besoin de la connexion SSH initiale (TCP 22 par défaut) ainsi que d'un port UDP par session, choisi entre 60000 et 61000. Pour éviter d'exposer toute cette plage, fixez une plage courte avec mosh -p 60000:60010 et n'autorisez que cette plage dans ufw, iptables ou le groupe de sécurité de votre fournisseur cloud.

Quels ports Mosh utilise : TCP pour SSH, UDP 60000-61000 pour la session

Mosh lance mosh-server via une connexion SSH initiale, puis toute la session passe par UDP. Il faut donc deux ouvertures distinctes sur le serveur : le port SSH (TCP 22 par défaut dans OpenSSH) et un port UDP dans la plage 60000-61000.

La plage par défaut compte 1001 ports. Chaque mosh-server écoute sur son propre port, la plage n'a donc qu'à couvrir les sessions simultanées que vous prévoyez sur cette machine. Sur un VPS que vous administrez seul, cela représente quelques sessions, pas un millier.

Quand SSH fonctionne mais que les paquets UDP n'arrivent jamais, le client se contente d'attendre : l'authentification a réussi et le terminal reste figé. C'est le symptôme classique d'un pare-feu qui laisse passer le port 22 et bloque la plage UDP.

Fixer le port UDP de Mosh avec mosh -p : un seul port ou une plage courte

L'option -p (ou --port) du client indique à mosh-server sur quel port UDP se lier, ou dans quelle plage chercher un port libre, sous la forme PORT ou PORT:PORT2. Sans elle, Mosh choisit un port entre 60000 et 61000.

# One specific UDP port
mosh -p 60001 user@server

# A short range: mosh-server takes the first free port
mosh -p 60000:60010 user@server

# SSH listening somewhere other than 22
mosh --ssh="ssh -p 2222" -p 60000:60010 user@server

Un seul port fixe est l'option la plus restrictive, mais elle n'autorise qu'une session à la fois : une deuxième connexion avec le même -p ne peut pas se lier au port tant que la première est active. Une plage de onze ports laisse de la place pour plusieurs sessions et l'occasionnel mosh-server orphelin sans ouvrir tout le bloc. La syntaxe complète du client et du serveur se trouve dans la documentation officielle de Mosh.

Règles ufw pour Mosh : pourquoi 60000:61010/udp ouvre plus que nécessaire

sudo ufw allow 60000:61010/udp est recopié de tutoriel en tutoriel, et ouvre dix ports au-delà de la plage par défaut de Mosh, qui s'arrête à 61000. Si vous fixez aussi une plage avec mosh -p, la démarche cohérente est d'ouvrir exactement cette plage et rien d'autre.

# SSH first, so enabling ufw does not lock you out
sudo ufw allow 22/tcp

# Only the range mosh -p will use
sudo ufw allow 60000:60010/udp

# Remove the wide rule if it is already there
sudo ufw delete allow 60000:61010/udp

sudo ufw enable
sudo ufw status numbered

ufw exige un protocole dès que vous ouvrez une plage de ports, d'où le /udp dans la règle. Avant d'exécuter ufw enable sur une machine distante, vérifiez que la règle SSH figure dans la liste : sans elle, vous perdez aussi la connexion initiale dont Mosh a besoin pour lancer mosh-server.

Mosh dans les groupes de sécurité cloud et avec iptables

Un groupe de sécurité cloud filtre avant que le paquet n'atteigne la machine, tandis qu'ufw ou iptables filtrent à l'intérieur : Mosh a besoin que la plage UDP soit ouverte dans les deux couches. N'en ouvrir qu'une seule produit la même session qui s'authentifie puis ne répond jamais.

# iptables, on the server itself
sudo iptables -A INPUT -p udp --dport 60000:60010 -j ACCEPT

# AWS security group, via the CLI
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol udp --port 60000-60010 \
  --cidr 0.0.0.0/0

La source 0.0.0.0/0 est volontaire : un téléphone qui passe du Wi-Fi aux données mobiles change d'adresse IP, et Mosh poursuit la session depuis la nouvelle adresse. Restreindre la source à l'IP de votre domicile ou de votre bureau casse précisément ce basculement. Si le serveur ne doit accepter aucun trafic internet, la solution est un réseau privé, pas une liste blanche d'IP.

Mosh vs SSH vs réseaux maillés : ce que chaque option expose

Mosh ne fait ni redirection de ports ni redirection X11, il ne remplace donc pas SSH pour les tunnels -L ou -R. Le tableau résume ce que chaque option ouvre sur le serveur et son comportement depuis un téléphone.

Méthode d'accès	Ports entrants sur le serveur	Passage du Wi-Fi aux données mobiles	Redirection de ports
SSH seul	TCP 22	La connexion tombe ; tmux garde les tâches en cours	Oui, avec -L et -R
Mosh, plage par défaut	TCP 22 et UDP 60000-61000	La session continue	Non
Mosh avec -p 60000:60010	TCP 22 et UDP 60000-60010	La session continue	Non
Réseau maillé privé	Aucun ouvert sur internet	Mosh fonctionne de la même façon dans le réseau	Celle de SSH, si vous l'utilisez

Avec un réseau maillé privé, sans ports ouverts comme Prialo, ou avec Tailscale, vous pouvez atteindre des machines sans IP publique et sans ports ouverts sur internet ; Mosh et SSH conservent leurs ports habituels, mais uniquement à l'intérieur de ce réseau.

4 erreurs en ouvrant les ports UDP pour Mosh

Coller 60000:61010 sans vérifier. La plage par défaut de Mosh s'arrête à 61000 ; si vous en fixez une autre avec -p, ouvrez exactement celle-là.
N'ouvrir qu'une seule couche. Une règle ufw mais aucune règle de groupe de sécurité, ou l'inverse : SSH passe, UDP non.
Filtrer par IP source. Le téléphone change d'IP en passant aux données mobiles, et la règle tue la session que Mosh maintenait en vie.
Manquer de ports libres. Les processus mosh-server de sessions abandonnées continuent d'occuper des ports de la plage. Repérez-les avec ss -ulpn | grep mosh-server et arrêtez-les avec kill et leur PID.

Utiliser Mosh depuis iOS et Android avec termi1

termi1 maintient la session avec Mosh quand vous passez du Wi-Fi aux données mobiles, et utilise tmux pour que ce que vous avez laissé tourner soit toujours là à votre retour ; côté serveur, les règles ci-dessus suffisent. Le clavier propre à termi1 dispose des touches Esc, Ctrl, Tab et des flèches, ce qui aide à modifier de longues règles ou à quitter un ufw status paginé sans lutter contre le clavier du système.

L'IA de termi1 transforme une phrase comme « ouvre les ports UDP de Mosh 60000 à 60010 dans ufw » en commande et la saisit à l'invite sans appuyer sur Entrée, pour que vous vérifiiez la plage avant de l'exécuter. Sur les connexions marquées comme production, Production Guard retient tout ce qui modifie l'état, comme une règle de pare-feu, avant que cela n'atteigne l'invite. L'IA n'ouvre jamais la session et ne reçoit pas les clés, et la clé privée ne quitte jamais le téléphone. Plus d'informations sur le terminal SSH et Mosh mobile.

Si le serveur est un Mac, termi1 Companion (macOS 14 ou ultérieur) vérifie que la connexion à distance, mosh-server et tmux sont disponibles avant que vous vous connectiez.

Questions fréquentes

Quels ports Mosh doit-il avoir ouverts dans le pare-feu ?

Mosh a besoin du port TCP de SSH, 22 par défaut, pour la connexion initiale, plus un port UDP par session dans la plage 60000-61000. Si vous fixez une plage avec mosh -p, il suffit d'ouvrir cette plage UDP à la fois dans le pare-feu et dans le groupe de sécurité.

Comment indiquer à Mosh quel port UDP utiliser ?

Le port UDP de Mosh se définit avec l'option -p ou --port du client, par exemple mosh -p 60001 user@server pour un port fixe ou mosh -p 60000:60010 pour une plage. mosh-server se lie au premier port libre dans la plage indiquée.

Pourquoi Mosh s'authentifie-t-il via SSH puis se bloque ?

Mosh s'authentifie via SSH en TCP puis bascule en UDP ; si le terminal se fige juste après l'authentification, un pare-feu ou un groupe de sécurité bloque la plage UDP. Vérifiez les deux couches et assurez-vous que la plage ouverte correspond à celle passée à mosh -p.

Mosh prend-il en charge la redirection de ports comme SSH ?

Mosh ne fait ni redirection de ports ni redirection X11. Pour des tunnels -L ou -R, il vous faut une connexion SSH distincte, ou un réseau maillé privé comme Prialo ou Tailscale pour atteindre directement le service interne sans ouvrir de ports.