Wie man das Problem behebt, dass die YaST-GUI über SSH X11-Weiterleitung nicht startet

Falls das grafische Fenster von YaST über SSH nicht funktioniert, prüfen Sie zunächst, ob die X11-Weiterleitung überhaupt funktioniert. Stellen Sie vom Client-Rechner aus eine Verbindung her ssh -X admin@serverund testen Sie anschließend ein anderes grafisches Programm. Falls sich dieses Programm öffnet, YaST aber eine XIO: fatal IO error 11Fehlermeldung wie z localhost:11.0. B. „x11“ anzeigt, bietet SUSE eine gezielte Problemumgehung: Führen Sie den betroffenen YaST-Befehl mit dem Parameter „--yast“ QT_XCB_GL_INTEGRATION=nonedavor aus. Verwenden Sie beispielsweise „--yast - ...QT_XCB_GL_INTEGRATION=none yast2 diskDISPLAY

Beginnen Sie mit den schnellsten Prüfungen.

Die grafische YaST-Oberfläche benötigt eine X-Anzeige auf Clientseite und einen funktionierenden SSH-X11-Tunnel. Der SSH-Client setzt DISPLAYauf dem Remote-Host einen Weiterleitungswert, wenn die Weiterleitung aktiviert ist. Eine einfache SSH-Anmeldung funktioniert auch dann, wenn die Grafik nicht weitergeleitet wird; daher bestätigt eine erfolgreiche Terminal-Sitzung allein noch nicht die X11-Funktionalität.

1. Stellen Sie sicher, dass auf dem Client-Computer ein aktiver X-Server oder eine X11-kompatible Anzeigesitzung vorhanden ist. Unter Windows beschreibt SUSE die Aktivierung der X11-Weiterleitung in PuTTY unter Verbindung > SSH > X11 ; ein lokaler X-Server muss ebenfalls verfügbar sein.
2. Stellen Sie die Verbindung mit aktivierter Weiterleitung wieder her: ssh -X admin@server. Verwenden Sie Ihren tatsächlichen Konto- und Hostnamen.
3. Überprüfen Sie auf der Remote-Shell echo "$DISPLAY", ob bei einer weitergeleiteten Anzeige ein Wert wie „x11“ localhost:10.0oder „x11 “ angezeigt wird localhost:11.0. Ein leerer Wert bedeutet, dass die Sitzung keine X11-Weiterleitung eingerichtet hat.
4. Starten Sie eine kleine X-Anwendung, die auf dem Remote-System installiert ist. Falls diese sich nicht auf Ihrem lokalen Desktop öffnen lässt, beheben Sie die Weiterleitung, bevor Sie YaST untersuchen.

Ein Administrator, der sich beispielsweise von einer Linux-Workstation aus verbindet, könnte `ssh` verwenden ssh -X ops@server.exampleund anschließend eine verfügbare Testanwendung ausführen. Wird das Anwendungsfenster lokal angezeigt, funktionieren der SSH-Tunnel und die lokale Anzeige. Andernfalls deutet eine Fehlermeldung wie „Anzeige kann nicht geöffnet werden“ auf den X11-Pfad hin und nicht auf eine YaST-spezifische Grafikumgehung.

Wenden Sie die YaST-spezifische Problemumgehung von SUSE an.

Der SUSE SLES 15 SP7 Deployment Guide beschreibt einen Fall, in dem die YaST-GUI über SSH mit X-Forwarding fehlschlägt XIO: fatal IO error 11 (Resource temporarily unavailable). localhost:11.0Die empfohlene Problemumgehung besteht darin, die XCB GL-Integration von Qt für diesen einen Befehl zu deaktivieren. Führen Sie den Befehl für das benötigte Modul aus, zum Beispiel:

QT_XCB_GL_INTEGRATION=none yast2 disk

Für die YaST-Installationsschnittstelle gibt die gleiche Anleitung folgendes Beispiel an:

QT_XCB_GL_INTEGRATION=none yast.ssh

Verwenden Sie den Befehl, der Ihrer Aufgabe entspricht; yast2 disköffnet das Festplattenmodul, während yast.sshfür den Installationsablauf gezeigt wird. Durch das Voranstellen eines einzelnen Befehls bleibt die Einstellung auf diesen Start beschränkt. Fügen Sie sie nicht dauerhaft einem globalen Shell-Profil hinzu, es sei denn, Sie haben einen triftigen Grund, das Qt-Verhalten für andere Programme zu ändern.

Diese Lösung ist besonders relevant, wenn X11 selbst funktioniert, YaST aber beendet wird oder den spezifischen XIO-Fehler ausgibt. Sollte der Fehler weiterhin bestehen, testen Sie ein anderes Modul und überprüfen Sie die Weiterleitungseinstellungen auf Client- und Serverseite. Andere Grafikfehler können unterschiedliche Ursachen haben; die SUSE-Lösung behebt nicht alle Qt-, GPU- oder Anzeigeprobleme.

Überprüfen Sie den SSH-Server, wenn DISPLAY leer ist.

Auf dem SUSE-Server muss die X11-Weiterleitung in der SSH-Daemon-Konfiguration aktiviert sein. Ein Administrator kann überprüfen /etc/ssh/sshd_configund bestätigen, dass die effektive Konfiguration Folgendes umfasst:

X11Forwarding yes

Serverrichtlinien können auch über mitgelieferte Konfigurationsdateien bereitgestellt oder zentral verwaltet werden. Gehen Sie daher nicht davon aus, dass die Bearbeitung einer einzelnen Zeile ausreicht. Überprüfen Sie nach einer autorisierten Änderung die Konfiguration und laden Sie den Dienst neu.

sudo sshd -t
sudo systemctl reload sshd.service

Lassen Sie die aktuelle SSH-Sitzung während der Konfigurationsprüfung geöffnet und testen Sie eine zweite Anmeldung, bevor Sie sie schließen. Eine Syntaxprüfung erkennt fehlerhafte Konfigurationen, stellt aber nicht sicher, dass die Richtlinie korrekt ist oder die Weiterleitung vom Client aus funktioniert. Wenn Sie den SSH-Server nicht selbst verwalten, bitten Sie dessen Administrator, die gültige Richtlinie zu überprüfen, anstatt selbst Systemdateien zu bearbeiten.

Stellen Sie nach jeder serverseitigen Änderung die Verbindung wieder her und wiederholen Sie die DISPLAYTests der Remote-Anwendung. Meldet der Server ein Autorisierungsproblem, prüfen Sie, ob der Remote-Benutzer über einen gültigen X-Autorisierungseintrag verfügt xauth list. Vermeiden Sie es, Autorisierungs-Cookies manuell zu kopieren oder die Zugriffskontrollen für die Anzeige zu schwächen, um das Fenster zu öffnen.

Führen Sie YaST mit Administratorrechten aus, ohne die Anzeige zu verlieren.

YaST ändert Systemeinstellungen und benötigt in der Regel Administratorrechte. Häufig entsteht Verwirrung, weil ein Benutzer ohne Administratorrechte zwar ein Testfenster anzeigen kann, YaST aber nach der Rechteerweiterung nicht mehr funktioniert. Der Prozess mit erhöhten Rechten speichert möglicherweise nicht die weitergeleiteten DISPLAYoder die X-Autorisierungsdaten, die für die Verbindung erforderlich sind.

Verwenden Sie die von Ihrer Organisation genehmigte Methode zur Rechteerweiterung und prüfen Sie, welche Berechtigungen der YaST-Prozess erhält. Aktivieren Sie nicht die direkte SSH-Anmeldung als Root, nur um eine grafische Benutzeroberfläche zu erhalten. Die Sicherheitsrichtlinien von SUSE empfehlen, sich als Benutzer ohne Root-Rechte anzumelden und sudoRoot-Befehle mit `sudo` auszuführen. Falls Ihre `sudo`-Richtlinie Umgebungsvariablen für die Anzeige absichtlich filtert, bitten Sie einen Administrator um eine speziell dafür vorgesehene, genehmigte Methode. Vermeiden Sie weitreichende Regeln zur Umgebungserhaltung oder Befehle, die die lokale Anzeige für alle Benutzer des Hosts zugänglich machen.

Die relevante Diagnoseunterscheidung ist einfach: Wenn eine X-Anwendung mit Ihrem normalen Benutzerkonto geöffnet wird, YaST aber nur mit erhöhten Rechten fehlschlägt, konzentrieren Sie sich auf die Rechte- und Autorisierungsübergabe. Wenn beides mit dem normalen Benutzerkonto fehlschlägt, überprüfen Sie erneut die Einstellungen für den SSH-Client, den lokalen X-Server und die Serverweiterleitung.

Wählen Sie die Textschnittstelle, wenn keine Grafiken erforderlich sind.

X11-Weiterleitung ist nützlich, wenn ein bestimmter Workflow die grafische Oberfläche zwingend erfordert, führt aber zu zusätzlichen Abhängigkeiten und kann bei Verbindungen mit hoher Latenz zu Verzögerungen führen. YaST bietet außerdem eine ncurses-Textschnittstelle für Terminal-Sitzungen. SUSE dokumentiert die Erzwingung dieser Schnittstelle für das Festplattenmodul mit folgendem Befehl:

yast2 disk --ncurses

Dies ist eine sinnvolle Wahl auf einem Server ohne grafische Oberfläche, wenn der Client keinen X-Server besitzt oder die grafische Sitzung instabil ist. Sie können YaST-Module auch über die Kommandozeile ausführen, sofern deren Optionen dies zulassen. Überprüfen Sie die Modulliste mit `yast list` yast -lund konsultieren Sie die Hilfe des jeweiligen Moduls, anstatt anzunehmen, dass jedes grafische Modul über entsprechende Kommandozeilenfunktionen verfügt.

Leitfaden von den Symptomen zur Handlung

Sicherheits- und Versionshinweise

X11-Weiterleitung bietet mehr als nur eine visuelle Vereinfachung: Grafikprogramme auf entfernten Systemen kommunizieren mit dem Bildschirm des Clients. Verwenden Sie sie nur für Systeme, denen Sie vertrauen. OpenSSH unterscheidet zwischen nicht vertrauenswürdiger und -Xvertrauenswürdiger Weiterleitung -Y. Vertrauenswürdige Weiterleitung ermöglicht entfernten X11-Clients einen umfassenderen Zugriff auf den lokalen Bildschirm. Beginnen Sie mit der nicht vertrauenswürdigen Weiterleitung -X. Ziehen Sie die Weiterleitung für einen vertrauenswürdigen Host nur dann in Betracht -Y, wenn eine bestimmte Anwendung dies erfordert und Ihre Sicherheitsrichtlinie dies zulässt.

Der oben beschriebene YaST-Fehler und die Problemumgehung sind im SUSE Linux Enterprise Server 15 SP7 Deployment Guide verifiziert. YaST-Module, verfügbare grafische Oberflächen und das Startverhalten können sich je nach SLES-, SLED- und openSUSE-Version unterscheiden. Prüfen Sie die Dokumentation für das exakt auf dem Remote-Host installierte Produkt und die Version. Geprüft am 6. Oktober 2026.

Referenzen: SUSE SLES 15 SP7 Bereitstellungshandbuch: YaST über SSH ; SUSE SLES 15 SP7 Sicherheits- und Härtungshandbuch: OpenSSH ; SUSE SLES 15 SP7 Handbuch: X Window System und Authentifizierung ; SUSE SLES 15 SP7 Administrationshandbuch: YaST-Textmodus und Befehlszeilenoptionen .