Comment résoudre le problème de lancement de l'interface graphique de YaST via le transfert X11 SSH

Si la fenêtre graphique de YaST ne s'affiche pas correctement via SSH, vérifiez d'abord si le transfert X11 fonctionne. Depuis l'ordinateur client, connectez-vous avec `ssh` ssh -X admin@server, puis testez un autre programme graphique distant. Si ce programme s'ouvre mais que YaST affiche XIO: fatal IO error 11un message d'erreur tel que localhost:11.0`<x11>`, SUSE propose une solution de contournement : exécutez la commande YaST concernée en QT_XCB_GL_INTEGRATION=noneajoutant `--x11` devant. Par exemple, utilisez `ssh` QT_XCB_GL_INTEGRATION=none yast2 disk. Cette solution s'applique aux problèmes de transfert Qt/OpenGL ; elle ne résoudra pas les problèmes liés à un serveur X local manquant, à un serveur X non configuré DISPLAY, à un transfert de serveur bloqué ou à un module YaST non installé.

Commencez par les vérifications les plus rapides

L'interface graphique YaST nécessite un affichage X côté client et un tunnel SSH X11 fonctionnel. Le client SSH configure une DISPLAYvaleur de redirection sur l'hôte distant lorsque la redirection est active. Une connexion SSH classique reste possible même sans redirection graphique ; par conséquent, une session terminal réussie ne suffit pas à confirmer l'utilisation de X11.

1. Assurez-vous que l'ordinateur client dispose d'un serveur X actif ou d'une session d'affichage compatible X11. Sous Windows, la documentation SUSE explique comment activer le transfert X11 dans PuTTY via Connexion > SSH > X11 ; un serveur X local doit également être disponible.
2. Reconnectez-vous avec le transfert activé : ssh -X admin@server. Utilisez votre compte et votre nom d’hôte réels.
3. Sur le terminal distant, vérifiez echo "$DISPLAY". Avec un affichage transféré, la valeur affichée devrait normalement être telle que localhost:10.0ou localhost:11.0. Une valeur vide signifie que la session n'a pas établi de transfert X11.
4. Lancez une petite application X installée sur le système distant. Si elle ne s'ouvre pas sur votre ordinateur, corrigez la redirection avant de tenter de résoudre le problème avec YaST.

Par exemple, un administrateur se connectant depuis un poste de travail Linux peut utiliser la commande `ssh -s` ssh -X ops@server.example, puis exécuter une application de test disponible. Si la fenêtre de l'application s'affiche localement, le tunnel SSH et l'affichage local fonctionnent correctement. Dans le cas contraire, une erreur telle que « Impossible d'ouvrir l'affichage » indique un problème avec le chemin X11 plutôt qu'avec une solution graphique spécifique à YaST.

Appliquez la solution de contournement spécifique à YaST de SUSE

Le guide de déploiement de SLES 15 SP7 de SUSE documente un cas où l'interface graphique YaST via SSH avec transfert X échoue XIO: fatal IO error 11 (Resource temporarily unavailable). localhost:11.0La solution recommandée consiste à désactiver l'intégration XCB GL de Qt pour cette commande. Exécutez la commande du module souhaité, par exemple :

QT_XCB_GL_INTEGRATION=none yast2 disk

Concernant l'interface d'installation de YaST, le même guide donne cet exemple :

QT_XCB_GL_INTEGRATION=none yast.ssh

Utilisez la commande correspondant à votre tâche ; yast2 diskelle ouvre le module disque, tandis que celle-ci yast.sshest affichée pour le processus d'installation. Préfixer une commande permet de limiter le paramètre à ce lancement. Ne l'ajoutez pas de façon permanente à un profil shell global, sauf si vous avez une autre raison de modifier le comportement de Qt pour d'autres programmes.

Ce correctif est particulièrement pertinent lorsque X11 fonctionne correctement mais que YaST se ferme ou affiche l'erreur XIO spécifique. Si l'erreur persiste, testez un autre module et vérifiez la configuration de redirection côté client et serveur. D'autres problèmes graphiques peuvent avoir des causes différentes ; la solution de contournement SUSE ne résout pas tous les problèmes liés à Qt, au GPU ou à l'affichage.

Vérifiez le serveur SSH lorsque DISPLAY est vide.

Sur le serveur SUSE, le transfert X11 doit être autorisé par la configuration du démon SSH. Un administrateur peut vérifier /etc/ssh/sshd_configque la configuration effective inclut bien :

X11Forwarding yes

La politique du serveur peut également être définie via des fichiers de configuration inclus ou gérée de manière centralisée ; par conséquent, ne considérez pas qu’une seule ligne de modification suffit. Après une modification autorisée, validez la configuration et redémarrez le service.

sudo sshd -t
sudo systemctl reload sshd.service

Gardez la session SSH ouverte pendant la vérification de la configuration et effectuez un second test de connexion avant de la fermer. Une vérification de syntaxe permet de détecter les configurations incorrectes, mais ne garantit pas la validité de la politique ni le bon fonctionnement du transfert de paquets depuis le client. Si vous n'administrez pas le serveur SSH, demandez à son administrateur de vérifier la politique en vigueur plutôt que de modifier vous-même les fichiers système.

Après toute modification côté serveur, reconnectez-vous et répétez les DISPLAYtests de l'application distante. Si le serveur signale un problème d'autorisation, vérifiez si l'utilisateur distant dispose d'une autorisation X valide xauth list. Évitez de copier manuellement les cookies d'autorisation ou d'affaiblir les contrôles d'accès à l'affichage pour permettre l'ouverture de la fenêtre.

Exécutez YaST avec des privilèges d'administrateur sans perdre l'affichage.

YaST modifie les paramètres système et requiert généralement une autorisation d'administrateur. Il arrive fréquemment qu'un utilisateur non privilégié puisse afficher une fenêtre de test, mais que YaST échoue après l'élévation des privilèges. Le processus avec privilèges élevés peut ne pas conserver les DISPLAYdonnées d'autorisation transmises ou les données d'autorisation X nécessaires à la connexion.

Utilisez la méthode d'élévation de privilèges approuvée par votre organisation et vérifiez les informations reçues par le processus YaST. N'activez pas la connexion SSH directe en tant que root uniquement pour obtenir une interface graphique ; les recommandations de sécurité de SUSE préconisent de se connecter en tant qu'utilisateur non privilégié et d'utiliser `sudo` sudopour les commandes root. Si votre politique `sudo` filtre intentionnellement les variables d'environnement liées à l'affichage, demandez à un administrateur de vous fournir une méthode approuvée et ciblée. Évitez les règles de préservation de l'environnement trop générales ou les commandes qui exposent l'affichage local à tous les utilisateurs de l'hôte.

La distinction diagnostique pertinente est simple : si une application X s’ouvre avec votre compte utilisateur habituel, mais que YaST échoue uniquement lorsque vous avez des privilèges élevés, concentrez-vous sur le transfert des privilèges et de l’autorisation. Si les deux échouent avec votre compte utilisateur habituel, vérifiez la configuration du client SSH, du serveur X local et du transfert de serveur.

Choisissez l'interface texte lorsque les graphismes ne sont pas nécessaires.

Le transfert X11 est utile lorsqu'un flux de travail particulier requiert une interface graphique, mais il ajoute des dépendances et peut s'avérer lent sur une connexion à latence élevée. YaST fournit également une interface texte ncurses pour les sessions de terminal. La documentation SUSE indique comment forcer son utilisation pour le module disque :

yast2 disk --ncurses

C'est une option pratique sur un serveur sans interface graphique, lorsque le client ne dispose pas de serveur X ou lorsque la session graphique est instable. Vous pouvez également exécuter des modules YaST en ligne de commande lorsque leurs options le permettent. Consultez la liste des modules avec `yast` yast -let référez-vous à l'aide du module concerné plutôt que de supposer que chaque module graphique possède des opérations en ligne de commande équivalentes.

Guide des symptômes à la conduite à tenir

Notes de sécurité et de version

Le transfert X11 est plus qu'un simple confort visuel : les programmes graphiques distants communiquent avec l'affichage du client. Utilisez-le uniquement avec des systèmes de confiance. OpenSSH distingue le transfert non fiable -Xdu transfert fiable-Y ; ce dernier offre aux clients X distants un accès plus étendu à l'affichage local. Commencez par `--trusted` -X. N'envisagez le transfert X11 -Ypour un hôte de confiance que si une application spécifique l'exige et que votre politique de sécurité le permet.

L'erreur YaST et la solution de contournement décrites ci-dessus sont documentées dans le Guide de déploiement de SUSE Linux Enterprise Server 15 SP7. Les modules YaST, les interfaces graphiques disponibles et le comportement au démarrage peuvent varier selon les versions de SLES, SLED et openSUSE. Consultez la documentation pour connaître la version exacte du produit installée sur l'hôte distant. Mise à jour le 6 octobre 2026.

Références : Guide de déploiement SUSE SLES 15 SP7 : YaST sur SSH ; Guide de sécurité et de renforcement SUSE SLES 15 SP7 : OpenSSH ; Guide SUSE SLES 15 SP7 : Système X Window et authentification ; Guide d'administration SUSE SLES 15 SP7 : Mode texte YaST et options de ligne de commande .