Redirection X11 : ssh -X vs -Y, sshd_config et alternatives

La redirection X11 via SSH permet d'exécuter une application graphique sur un serveur Linux et d'afficher sa fenêtre sur votre machine locale. Elle est utile lorsque vous avez besoin ponctuellement d'un outil graphique et que votre client dispose d'un serveur X. Utilisez ssh -X par défaut, -Y uniquement avec des serveurs de totale confiance, et définissez X11Forwarding yes dans sshd_config.

ssh -X vs ssh -Y : ce qui change dans la redirection X11 d'OpenSSH

ssh -X active la redirection X11 et traite les applications distantes comme non fiables, soumises aux contrôles de l'extension X11 SECURITY. ssh -Y active la redirection X11 de confiance et supprime ces contrôles. Dans les deux cas, le trafic X est chiffré dans la session SSH et le serveur définit DISPLAY pour que les fenêtres arrivent sur votre écran.

La différence porte sur la sécurité. La page de manuel de ssh avertit que toute personne capable de contourner les permissions de fichiers sur l'hôte distant peut atteindre votre affichage local via la connexion redirigée et, par exemple, surveiller vos frappes au clavier. Avec -Y, cet accès est illimité ; avec -X, il est restreint, au prix du dysfonctionnement de certaines applications.

Utilisez -X par défaut, et toujours sur les hôtes partagés ou les serveurs que vous n'administrez pas.
Utilisez -Y uniquement lorsque l'application échoue avec -X et que vous faites entièrement confiance au serveur.
Vérifiez ForwardX11Trusted dans le ssh_config global du système : certaines distributions le modifient, et -X se comporte alors comme -Y.

Comment activer X11Forwarding sur le serveur SSH et le tester

Le serveur n'accepte la redirection X11 que si /etc/ssh/sshd_config contient X11Forwarding yes et que le programme xauth est installé ; si l'un des deux manque, la demande du client est refusée. Voici la configuration minimale des deux côtés :

# Server: /etc/ssh/sshd_config
X11Forwarding yes
X11UseLocalhost yes

# Check syntax and reload the service
sudo sshd -t
sudo systemctl reload sshd   # on Debian/Ubuntu the service is called ssh

# Client: one-off connection
ssh -X user@server
echo $DISPLAY                # something like localhost:10.0
xclock &

# Client: ~/.ssh/config
Host lab
    HostName lab.example.com
    User user
    ForwardX11 yes
    ForwardX11Trusted no

Les directives documentées de sshd_config couvrent le reste : X11UseLocalhost yes lie l'affichage redirigé uniquement à l'interface de bouclage du serveur, et X11DisplayOffset fixe le premier numéro d'affichage attribué par sshd, d'où le :10 habituel. Quand quelque chose ne fonctionne pas, ssh -v -X user@server vous indique pourquoi :

X11 forwarding request failed on channel 0 : le serveur a X11Forwarding no ou n'a pas xauth.
Can't open display renvoyé par l'application : en général DISPLAY est vide parce que la session n'a jamais demandé la redirection, ou aucun serveur X local n'est en cours d'exécution.

Redirection X11 sur iOS et Android vs ordinateur : ce qu'il faut de chaque côté

La redirection X11 nécessite un serveur X sur la machine cliente, car c'est elle qui dessine les fenêtres. Un bureau Linux en possède généralement un ; macOS nécessite l'installation de XQuartz ; un client SSH mobile est normalement un terminal sans serveur X.

Critère	Ordinateur avec ssh -X	Téléphone iOS/Android	Alternative : tunnel -L ou SFTP
Serveur X local	Requis : X11, XWayland ou XQuartz	Généralement indisponible dans le terminal	Inutile
Fonctionne avec Mosh	Mosh ne redirige pas X11 ; SSH nécessaire	Mosh conserve le terminal, sans fenêtres X	Le tunnel -L nécessite SSH, pas Mosh
Passage du wifi aux données mobiles	La session SSH et ses fenêtres tombent	Avec Mosh et tmux, la session survit	Le tunnel se rouvre ; tmux maintient les processus
Risque pour la machine locale	Avec -Y, accès illimité à l'affichage	Aucun affichage X exposé	Seul le port redirigé est exposé
Usage idéal	Outil graphique ponctuel sur un réseau stable	Administration en terminal et fichiers	Interfaces web, graphiques et documents

termi1 est un terminal SSH, Mosh et SFTP, et Mosh, par conception, ne fait ni redirection de ports ni redirection X11. Ce qu'il résout sur un téléphone est différent : maintenir la session active lorsque vous passez du wifi aux données mobiles, et retrouver tmux avec tout ce que vous y aviez laissé en cours.

4 alternatives à la redirection X11 SSH qui fonctionnent depuis un téléphone

ssh -L redirige un port local vers un service du serveur et couvre de nombreux cas qui impliquaient autrefois une fenêtre X : tableaux de bord web, notebooks ou consoles d'administration écoutant sur localhost.

# Forward the server's port 8080 to your machine
ssh -N -L 8080:localhost:8080 user@server
# Then open http://localhost:8080 in your local browser

Tunnel de port avec ssh -L : affiche les interfaces web du serveur dans votre navigateur local, sans serveur X, dans tout client prenant en charge la redirection de ports.
Télécharger le résultat via SFTP : si l'application graphique servait uniquement à visualiser un graphique, un PDF ou une image, générez le fichier sur le serveur et récupérez-le. Le SFTP intégré de termi1 le fait sans quitter la session.
Outils texte dans tmux : htop, journalctl ou un éditeur en terminal remplacent de nombreux moniteurs graphiques. Le clavier de termi1 ajoute Échap, Ctrl et F1–F12, que ces outils utilisent sans cesse.
Bureau à distance via un réseau privé : si vous avez besoin d'un bureau complet, un réseau maillé privé Prialo ou Tailscale atteint la machine sans IP publique ni ports ouverts.

Quand la redirection X11 SSH a encore du sens en 2026

La redirection X11 vaut la peine lorsque trois conditions sont réunies : l'application graphique n'existe que sur le serveur, vous en avez besoin brièvement, et vous êtes sur un ordinateur avec un serveur X et un réseau stable. En dehors de ce cas, les alternatives ci-dessus sont plus simples et exposent moins.

Cas raisonnables : un installateur graphique, un outil de diagnostic d'un fournisseur ou une visionneuse sans version web. Cas à éviter : -Y par habitude, ForwardX11 yes sous Host *, ou X11Forwarding yes sur des serveurs de production que personne n'utilise en mode graphique ; là, X11Forwarding no est le bon réglage.

Depuis un téléphone, le flux pratique consiste à se connecter avec Mosh, rattacher tmux et travailler en mode texte. Si vous ne vous souvenez plus de la syntaxe de ssh -L, l'IA du terminal SSH et Mosh termi1 saisit la commande à l'invite sans appuyer sur Entrée, et sur les connexions marquées production, Production Guard bloque tout ce qui supprime, arrête ou modifie quelque chose.

Questions fréquentes

Quelle est la différence entre ssh -X et ssh -Y ?

La différence entre ssh -X et ssh -Y tient au niveau de confiance. -X redirige X11 en appliquant aux applications distantes les restrictions de l'extension X11 SECURITY ; -Y les considère comme fiables et leur donne un accès complet à votre affichage local. N'utilisez -Y qu'avec des serveurs que vous contrôlez.

Pourquoi SSH affiche-t-il X11 forwarding request failed on channel 0 ?

Le message X11 forwarding request failed on channel 0 signifie que le serveur a refusé la redirection X11. Les causes habituelles sont X11Forwarding no dans /etc/ssh/sshd_config ou l'absence du programme xauth sur le serveur. Corrigez la directive, installez xauth, rechargez sshd et ouvrez une nouvelle session.

La redirection X11 fonctionne-t-elle avec Mosh ?

La redirection X11 ne fonctionne pas avec Mosh. Mosh utilise UDP, par défaut sur les ports 60000-61000, lance mosh-server via une connexion SSH initiale et ne fait ni redirection de ports ni redirection X11. Pour ouvrir des fenêtres X, il vous faut une session SSH classique avec -X ou -Y.

Puis-je utiliser la redirection X11 depuis un iPhone ou un téléphone Android ?

La redirection X11 depuis un iPhone ou un téléphone Android ne fonctionne que si le client intègre un serveur X pour dessiner les fenêtres, ce qui est rare dans les terminaux mobiles. En pratique, un tunnel ssh -L vers une interface web, le téléchargement du résultat via SFTP ou des outils texte dans tmux fonctionnent mieux.