Startseite
» LINUX
»
Wie man X11-Weiterleitung unter Linux über SSH einrichtet
Wie man X11-Weiterleitung unter Linux über SSH einrichtet
Mit X11-Weiterleitung können Sie eine grafische Linux-Anwendung auf einem entfernten Computer ausführen und deren Fenster über SSH auf Ihrem lokalen Desktop anzeigen. Aktivieren Sie dazu die Weiterleitung auf dem entfernten SSH-Server, stellen Sie sicher, xauthdass der Server X11 unterstützt, prüfen Sie, ob Ihr lokaler Desktop über eine X-Anzeige verfügt, und stellen Sie die Verbindung her ssh -X. Dadurch werden einzelne Anwendungsfenster weitergeleitet; es wird keine vollständige Remote-Desktop-Sitzung erstellt.
Was Sie vor der Einrichtung benötigen
Der Computer, auf dem Sie den SSH-Befehl eingeben, ist der Client . Er benötigt den OpenSSH-Client und eine aktive grafische Desktop-Sitzung mit einer X-Oberfläche. Viele Linux-Desktops stellen dies direkt oder über XWayland bereit, wenn die Sitzung Wayland verwendet. Wenn echo "$DISPLAY"auf dem lokalen Desktop nichts ausgegeben wird, steht SSH in dieser Shell keine Oberfläche zur Verfügung.
Der Remote-Computer fungiert als Server . Er benötigt den OpenSSH-Server und das xauthentsprechende Hilfsprogramm, damit SSH den temporären Autorisierungs-Cookie für die weitergeleitete Anzeige erstellen kann. Unter Debian oder Ubuntu installieren Sie diese auf dem Remote-System mit den Befehlen ` openssh` sudo apt updateund sudo apt install openssh-server xauth`openssh-server`. Bei anderen Distributionen verwenden Sie den jeweiligen Paketmanager, um den OpenSSH-Server und das zugehörige Hilfsprogramm zu installieren xauth. Stellen Sie sicher, dass eine normale SSH-Anmeldung funktioniert, bevor Sie die Konfiguration ändern.
Prüfen Sie, ob auf dem lokalen Terminal der OpenSSH-Client ausgeführt werden kann; der Remote-Server benötigt außerdem xauth.
X11-Weiterleitung über SSH einrichten
1. Aktivieren Sie die Weiterleitung in der Serverkonfiguration.
Bearbeiten Sie auf dem Remote-Computer die Serverkonfigurationsdatei , üblicherweise /etc/ssh/sshd_config, mit einem Editor mit Administratorrechten:
sudoedit /etc/ssh/sshd_config
Suchen Sie eine vorhandene aktive X11ForwardingEinstellung und ändern Sie diese wie folgt:
X11Forwarding yes
Falls die Einstellung fehlt, fügen Sie sie im globalen Abschnitt vor jedem MatchBlock hinzu. Einige Distributionen laden Dateien auch aus dem Verzeichnis `/etc/sshd_config` /etc/ssh/sshd_config.d/; prüfen Sie die eingebundenen Dateien auf Konflikte mit den Einstellungen. Eine MatchRegel DisableForwarding yeskann die Weiterleitung für ein bestimmtes Konto weiterhin verhindern. Belassen Sie X11UseLocalhostdie Standardeinstellung, es sei denn, Sie haben ein spezifisches Kompatibilitätsproblem: OpenSSH bindet den Weiterleitungsproxy normalerweise an Loopback. Das offizielle Handbuch zu `sshd_config` beschreibt diese serverseitigen Optionen.
Die Servereinstellungen gehören in die Datei sshd_config, nicht in die SSH-Client-Datei ssh_config.
2. Überprüfen Sie die Konfiguration und laden Sie SSH neu.
Vor dem Neuladen des Daemons prüfen Sie die Datei auf Syntaxfehler und bestätigen Sie den effektiven Weiterleitungswert:
Der erste Befehl sollte fehlerfrei ausgeführt werden; der zweite sollte eine Fehlermeldung ausgeben x11forwarding yes. Wenn Sie MatchRegeln verwenden, testen Sie die korrekte Konfiguration für den betreffenden Benutzer und die Verbindung gemäß der OpenSSH-Dokumentation. Beheben Sie alle Fehler, bevor Sie OpenSSH neu laden, um den SSH-Zugriff nicht zu unterbrechen.
Laden Sie den von Ihrer Distribution verwendeten Dienstnamen neu. Debian und Ubuntu verwenden üblicherweise:
sudo systemctl reload ssh
Fedora- und RHEL-basierte Systeme verwenden üblicherweise:
sudo systemctl reload sshd
Falls ein Neuladen nicht unterstützt wird, verwenden Sie restartstattdessen denselben Dienst. Halten Sie die aktuelle Sitzung geöffnet und testen Sie eine neue Verbindung, bevor Sie sie schließen. Die OpenSSH-Serverdokumentation von Ubuntu enthält Informationen zur Serverdatei und zu Konfigurationsbeispielen, die unter Ubuntu verwendet werden.
3. Stellen Sie eine Verbindung vom lokalen Linux-Desktop her.
Auf dem Client wird eine nicht vertrauenswürdige X11-Weiterleitung angefordert mit -X:
ssh -X user@server.example.com
Ersetzen Sie den Beispielbenutzernamen und Hostnamen durch Ihre eigenen. Falls der SSH-Server auf einem nicht standardmäßigen Port lauscht, fügen Sie dessen Portnummer mit einem Doppelpunkt hinzu -p:
ssh -X -p 2222 user@server.example.com
Nach der Anmeldung starten Sie ein auf dem Remote-Host installiertes grafisches Programm. Prüfen Sie zur schnellen Überprüfung, xclockob die Testanwendung verfügbar ist, oder starten Sie ein anderes installiertes GUI-Programm. SSH setzt den DISPLAYWert der Remote-Sitzung und leitet die X11-Verbindung automatisch weiter; kopieren Sie Ihren lokalen Anzeigewert nicht auf den Server und legen Sie ihn nicht manuell fest.
Die -XOption fordert X11-Weiterleitung beim Start der SSH-Sitzung an.Eine weitergeleitete GUI-Anwendung erscheint als Fenster auf dem lokalen Desktop, während die SSH-Sitzung geöffnet bleibt.
Sicherheit und Fehlerbehebung
-XStandardmäßig verwenden . Diese -YOption aktiviert die vertrauenswürdige Weiterleitung, wodurch die X11-Sicherheitsbeschränkungen aufgehoben werden und die Remote-Anwendung einen umfassenderen Zugriff auf Ihren lokalen Bildschirm erhält. Verwenden Sie diese Option nur mit einem Server und einer Anwendung, denen Sie vertrauen. OpenSSH warnt davor, dass die X11-Weiterleitung den Client-Bildschirm Angriffen aussetzen kann. Informationen zum Unterschied zwischen vertrauenswürdiger und nicht vertrauenswürdiger Weiterleitung finden Sie im SSH-Handbuch und im Handbuch zu ssh_config .
„X11-Weiterleitungsanforderung fehlgeschlagen“: Überprüfen Sie den effektiven Wert des Servers X11Forwarding, vergewissern Sie sich, dass xauther auf dem Remote-Host installiert ist, und suchen Sie nach einer einschränkenden MatchBlockierung oder DisableForwardingEinstellung.
DISPLAYWenn die Remotesitzung leer ist: Trennen Sie die Verbindung und stellen Sie sie mit erneuter Verbindung wieder her ssh -X. Stellen Sie sicher, dass die lokale Shell eine grafische Oberfläche anzeigt und die Verbindung den soeben konfigurierten Server erreicht.
Das Fenster meldet, dass kein Bildschirm geöffnet werden kann: Überprüfen Sie, ob Ihre lokale Desktop-Sitzung noch aktiv ist. Eine Shell ohne Zugriff auf den Desktop-Bildschirm kann keine weitergeleiteten Fenster anzeigen.
xclockwurde nicht gefunden: Das Testprogramm fehlt. Versuchen Sie es mit einer bereits auf dem Remote-Rechner installierten GUI-Anwendung; diese Meldung allein beweist nicht, dass die SSH-Weiterleitung defekt ist.
X11-Weiterleitung ist praktisch für gelegentliche Remote-Tools, aber grafische Anwendungen, die häufig neu gezeichnet werden, können bei einer Verbindung mit hoher Latenz träge wirken. Für einen kompletten Desktop oder grafikintensive Aufgaben sollten Sie eine speziell dafür entwickelte Remote-Desktop-Lösung verwenden.