SSH : activer le X11 forwarding sous Linux

Si vous avez besoin de lancer une application graphique depuis un serveur distant via SSH, le X11 forwarding permet d’afficher l’interface de cette application sur votre machine locale.

Le principe est simple : l’application tourne sur le serveur, mais son affichage graphique est transféré à travers la connexion SSH vers votre poste. C’est pratique pour lancer ponctuellement un outil graphique, tester une application X11, ouvrir un installeur visuel, utiliser xclock, xeyes, gedit, meld ou un utilitaire d’administration qui exige encore une interface.

En revanche, cette fonctionnalité n’est pas toujours activée côté serveur. Si vous obtenez l’erreur suivante lors de la connexion, il faut vérifier la configuration SSH :

X11 forwarding request failed on channel 0

Voici comment activer X11 forwarding proprement sur un serveur Debian, Ubuntu ou un serveur dédié Linux.

BigScoots: Premium WordPress and WooCommerce hosting

À quoi sert le X11 forwarding ?

X11 forwarding sert à transmettre l’affichage d’une application graphique distante vers votre écran local à travers SSH.

Contrairement à VNC ou RDP, il ne lance pas un bureau distant complet. Il transfère seulement l’affichage d’une ou plusieurs applications X11. C’est donc léger pour des outils ponctuels, mais moins confortable pour une session graphique complète.

Le client SSH demande le transfert X11 avec -X ou -Y. Le serveur SSH accepte ou refuse cette demande selon sa configuration. Si la demande est acceptée, SSH prépare une variable DISPLAY distante, généralement sous la forme localhost:10.0, puis gère l’authentification X11 avec xauth.

OpenSSH documente les directives X11Forwarding, X11DisplayOffset et X11UseLocalhost dans la configuration du serveur. Par défaut, X11Forwarding est désactivé côté serveur sur OpenSSH. Voir la page de manuel Debian de sshd_config.

Pré-requis côté client

Avant de modifier le serveur, vérifiez que votre machine locale peut recevoir des applications X11.

Sous Linux avec une session X11 classique, tout est souvent déjà prêt. Sous Wayland, beaucoup de distributions fournissent XWayland, ce qui permet encore d’afficher des applications X11. Sous macOS, il faut généralement installer et lancer XQuartz. Sous Windows, il faut utiliser un serveur X comme VcXsrv, Xming ou une solution équivalente.

Sur un client Linux, vous pouvez déjà vérifier votre environnement local avec :

echo "$DISPLAY"Code language: PHP (php)

Si la variable est vide sur votre poste local, le serveur distant n’aura pas grand-chose à vous renvoyer. Oui, c’est le principe de la télévision sans écran.

Étape 1 : installer xauth sur le serveur

Sur le serveur distant, xauth doit être installé. SSH l’utilise pour gérer les cookies d’authentification X11.

Sur Debian ou Ubuntu :

sudo apt update
sudo apt install xauth

Sur AlmaLinux, Rocky Linux, RHEL ou Fedora :

sudo dnf install xauth

Vous pouvez vérifier sa présence avec :

command -v xauth

La commande doit renvoyer un chemin, par exemple :

/usr/bin/xauth

Sans xauth, le transfert X11 échoue souvent ou produit des erreurs du type Fake authentication data, Can't open display ou X11 forwarding request failed.

Étape 2 : activer X11 forwarding côté serveur

Sur le serveur, éditez la configuration du daemon SSH :

sudo nano /etc/ssh/sshd_config

Vérifiez ou ajoutez ces directives :

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AllowTcpForwarding yes

Dans la plupart des cas, X11UseLocalhost yes est le bon choix : le serveur X11 virtuel créé par SSH écoute seulement sur l’interface locale du serveur distant. Cela limite l’exposition réseau.

Évitez de mettre X11UseLocalhost no sauf besoin très spécifique. Si vous devez le faire, comprenez bien l’impact réseau avant de l’activer.

Vérifiez ensuite que la configuration SSH est valide :

sudo sshd -t

Si la commande ne renvoie rien, la syntaxe est correcte.

Rechargez ensuite SSH. Sur Debian et Ubuntu, le service s’appelle souvent ssh :

sudo systemctl reload ssh

Sur certaines distributions, le service s’appelle plutôt sshd :

sudo systemctl reload sshd

Si le rechargement échoue, ne fermez pas votre session SSH actuelle avant d’avoir corrigé la configuration. Une session ouverte, c’est un parachute. Un parachute ouvert, c’est mieux.

Kinsta: Premium Managed WordPress hosting

Étape 3 : configurer le client SSH

On peut activer X11 forwarding ponctuellement avec une option en ligne de commande. C’est souvent la méthode la plus propre.

Pour une connexion X11 non fiable :

ssh -X utilisateur@serveurCode language: CSS (css)

Pour une connexion X11 de confiance :

ssh -Y utilisateur@serveurCode language: CSS (css)

La différence compte : -X active un transfert X11 non fiable, plus restrictif. -Y active un transfert X11 de confiance, moins restrictif, souvent nécessaire pour certaines applications graphiques modernes. OpenSSH documente également ForwardX11Trusted côté client, qui donne aux clients X11 distants un accès complet au serveur X11 original lorsqu’il est activé. Voir la page de manuel Ubuntu de ssh_config.

Si vous utilisez souvent le même serveur, ajoutez une configuration dédiée dans votre fichier utilisateur :

nano ~/.ssh/configCode language: JavaScript (javascript)

Par exemple :

Host mon-serveur-x11
    HostName exemple.com
    User matt
    ForwardX11 yes
    ForwardX11Trusted yesCode language: CSS (css)

Évitez de modifier /etc/ssh/ssh_config globalement si vous n’en avez pas besoin. Une configuration par hôte dans ~/.ssh/config reste plus précise et plus facile à maintenir.

Évitez aussi d’activer ForwardAgent yes par réflexe. Le transfert d’agent SSH n’est pas nécessaire pour X11 forwarding. Il sert à transmettre votre agent d’authentification SSH, ce qui répond à un autre besoin et mérite une décision séparée.

Le plus lu : Résoudre l'erreur 526 entre Cloudflare et NginX

Étape 4 : tester X11 forwarding

Connectez-vous au serveur avec X11 forwarding :

ssh -Y utilisateur@serveurCode language: CSS (css)

Une fois connecté, affichez la variable DISPLAY :

echo "$DISPLAY"Code language: PHP (php)

Si tout va bien, le serveur devrait renvoyer une valeur de ce type :

localhost:10.0Code language: CSS (css)

Vous pouvez ensuite tester avec une petite application X11. Sous Debian ou Ubuntu, installez par exemple x11-apps :

sudo apt install x11-apps

Puis lancez :

xclock

Ou, pour le test le plus inutilement satisfaisant :

xeyes

Si la fenêtre apparaît sur votre poste local, X11 forwarding fonctionne.

Codeable: trouvez les meilleurs développeurs WordPress

Corriger l’erreur “X11 forwarding request failed on channel 0”

Cette erreur indique généralement que le serveur SSH a refusé la demande de transfert X11 ou qu’un prérequis manque.

Commencez par vérifier la configuration effective du serveur :

sudo sshd -T | grep -i x11

Vous devriez obtenir quelque chose comme :

x11forwarding yes
x11displayoffset 10
x11uselocalhost yes

Vérifiez ensuite que xauth est disponible :

command -v xauth

Si rien ne s’affiche, installez xauth.

Enfin, relancez la connexion en mode verbeux pour voir où ça bloque :

ssh -vvv -Y utilisateur@serveurCode language: CSS (css)

Recherchez les lignes contenant X11, xauth ou DISPLAY. Elles donnent généralement la cause du problème.

Corriger l’erreur “Can’t open display”

L’erreur Can't open display signifie souvent que la variable DISPLAY est absente, incorrecte ou que le client local ne peut pas recevoir l’affichage.

Vérifiez côté serveur après connexion :

echo "$DISPLAY"Code language: PHP (php)

Si la variable est vide, reconnectez-vous avec -X ou -Y :

ssh -Y utilisateur@serveurCode language: CSS (css)

Si vous êtes sous macOS, vérifiez que XQuartz est lancé. Sous Windows, vérifiez que votre serveur X est démarré avant la connexion SSH. Sous Linux/Wayland, vérifiez que XWayland est disponible.

Faut-il utiliser ssh -X ou ssh -Y ?

La commande ssh -X active le transfert X11 standard, dit non fiable. Certaines applications peuvent toutefois ne pas fonctionner correctement avec ce mode, car elles demandent des accès X11 plus larges.

La commande ssh -Y active le transfert X11 de confiance. Elle fonctionne souvent mieux avec les applications graphiques modernes, mais elle accorde davantage de droits à l’application distante sur votre affichage local.

En pratique :

essayez d’abord ssh -X pour un usage ponctuel ;
utilisez ssh -Y si l’application ne se lance pas ou se comporte mal ;
réservez X11 forwarding aux serveurs que vous administrez ou auxquels vous faites confiance.

Le plus lu : Rsync: rapatrier les fichiers du serveur à la maison

Sur un serveur dédié personnel, -Y reste souvent le choix le plus simple. Sur un serveur partagé ou inconnu, ce serait nettement moins drôle.

Configuration recommandée

Pour un serveur dédié classique, voici une configuration serveur propre :

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AllowTcpForwarding yes

Et une configuration client par hôte dans ~/.ssh/config :

Host mon-serveur-x11
    HostName exemple.com
    User matt
    ForwardX11 yes
    ForwardX11Trusted yesCode language: CSS (css)

Ensuite, la connexion devient simplement :

ssh mon-serveur-x11

Et le test :

echo "$DISPLAY"
xclockCode language: PHP (php)

Quand éviter X11 forwarding ?

X11 forwarding est pratique, mais ce n’est pas toujours le bon outil.

Évitez-le si vous voulez utiliser un bureau distant complet, lancer des applications graphiques lourdes, faire de la 3D, travailler longtemps dans une interface visuelle ou fournir un accès graphique à plusieurs utilisateurs.

Dans ces cas, une autre solution sera souvent plus adaptée : RDP, VNC, X2Go, NoMachine, une interface web, ou tout simplement une alternative en ligne de commande.

Pour un serveur dédié, la meilleure interface graphique reste souvent celle qu’on n’installe pas. Mais quand il faut lancer ponctuellement une application X11, le forwarding SSH fait très bien le travail.

Résumé rapide

Pour activer X11 forwarding sur un serveur Debian ou Ubuntu :

installez xauth sur le serveur ;
activez X11Forwarding yes dans /etc/ssh/sshd_config ;
validez la configuration avec sshd -t ;
rechargez SSH avec systemctl reload ssh ou systemctl reload sshd ;
connectez-vous avec ssh -X ou ssh -Y ;
vérifiez echo "$DISPLAY" ;
testez avec xclock ou xeyes.

Si DISPLAY renvoie localhost:10.0 et qu’une application graphique s’ouvre sur votre poste local, c’est gagné.

Conclusion

Le X11 forwarding permet d’exécuter une application graphique distante à travers SSH sans installer de bureau complet sur le serveur.

La configuration tient en peu de choses : xauth installé, X11Forwarding yes côté serveur, puis une connexion avec ssh -X ou ssh -Y côté client.

Pour un serveur dédié, c’est idéal pour un besoin ponctuel : lancer un outil graphique, tester un affichage X11, ou dépanner une application qui refuse encore de vivre uniquement dans un terminal.

Et si le serveur vous répond localhost:10.0, vous pouvez sourire : le tunnel graphique est en place.