[gelöst] X11-Forwarding (SSH) für komplettes Desktop Environment

KDE, Gnome, Windowmanager, X11, Grafiktreiber und alles was dazu notwendig ist. Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
BenutzerGa4gooPh

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von BenutzerGa4gooPh » 12.02.2018 12:46:31

NAB hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 18:25:53
Jana66 hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 16:27:18
Probiere noch kurz (weil zukunftslos wegen Wayland) ein oder zwei X-Server,
X-Server werden auf Wayland weiterhin funktionieren.
Upps, ich nahm an, Wayland ersetzt künftig Xorg. Sollte ich wohl mal googeln.
MartinV hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 14:54:35
Alternativ kannst Du xinitrc-ssh auch so schreiben, dann bekommst Du ein nacktes xterm Fenster, in dem Du das Paßwort eingeben kannst:

Code: Alles auswählen

nano ~/xinitrc-ssh
#! /bin/sh
xterm -e ssh -X user@servername
aus VT2 (STRG+ALT+F2)

Code: Alles auswählen

xinit ~/xinitrc-ssh -- /usr/bin/X :2 vt2
funktioniert, kleines weißes Fenster mit SSH-Anmeldung am Server erscheint, Forwarding der xfce4 session ist (mit Fehlerausgaben) möglich:

Code: Alles auswählen

xfce4-session &
Der ursprüngliche X-Server in grafischer Konsole VT7 ist jedoch nicht mehr erreichbar, Lightdm-Login-Fenster nach Umschalten. Fehlermeldungen aus dem kompletten Journal nach Neuanmeldung suche ich mal nicht raus, etwas aufwändig, sorry.
Außerdem ist die Methode mit X-Forwarding über nichtgrafische Konsole sehr unpraktisch/unbequem, kein Copy/Paste.
Zuletzt geändert von BenutzerGa4gooPh am 12.02.2018 13:41:42, insgesamt 2-mal geändert.

BenutzerGa4gooPh

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von BenutzerGa4gooPh » 12.02.2018 13:21:36

smutbert hat geschrieben: ↑ zum Beitrag ↑
08.02.2018 00:14:52
Für die Variante mit X-Forwarding gibt es auch andere Möglichkeiten:
Debianxserver-xephyr oder Debianxnest hätte ich auch vorgeschlagen. Damit erhältst du einen neuen X-Server, der in ein eigenes Fenster zeichnet, in dem du einen eigenen WM oder auch ein komplettes DE laufen lassen kannst.
Das klappt gut, akzeptabel, halbwegs bequem, copy/paste aus Textdatei möglich, kein Wechsel virtueller Konsolen nötig. Beim Probieren mal notiert:

Auf Remote-Server mit DE (bei mir XFCE) muss nur SSH-Server installiert werden (apt install ssh), die SSH-Defaults des Servers nach Installation genügen für prinzipielle Funktion, keine weiteren Installationen erforderlich, alles Folgende auf SSH-Client:

Code: Alles auswählen

apt-get install xserver-xephyr
Xephyr :1 -ac -br -screen 1600x900 -reset -terminate &
(startet neues Fenster mit Xephyr ohne Eingabemöglichkeit, später mit Desktop des Servers)
im ursprünglichem Terminal:
DISPLAY=:1
ssh -X user@server
xfce4-session &
nach Beendigung Display zurücksetzen:
DISPLAY=:0
Bei Start der xfce4-session erscheinen Fehlermeldungen, das remote-System ist jedoch bedienbar.

Code: Alles auswählen

gpg-agent[1923]: WARNING: "--write-env-file" is an obsolete option - it has no effect
gpg-agent: a gpg-agent is already running - not starting a new one

(xfce4-session:1916): xfce4-session-WARNING **: gpg-agent returned no PID in the variables
/usr/share/system-config-printer/applet.py:45: PyGIWarning: Notify was imported without specifying a version first. Use gi.require_version('Notify', '0.7') before import to ensure that the right version gets loaded.
  from gi.repository import Notify
system-config-printer-applet: failed to start NewPrinterNotification service
system-config-printer-applet: failed to start PrinterDriversInstaller service: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.152" is not allowed to own the service "com.redhat.PrinterDriversInstaller" due to security policies in the configuration file
process 1977: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1367.
This is normally a bug in some application using the D-Bus library.

user@server:~$ 
(nm-applet:1980): libnotify-WARNING **: Failed to connect to proxy

(nm-applet:1980): nm-applet-WARNING **: Failed to show notification: Fehler beim Aufruf von StartServiceByName für org.freedesktop.Notifications: Zeitüberschreitung wurde erreicht
Wenn doch eine bestimmte Anwendung nicht bedienbar sein sollte, bleibt immer noch die Möglichkeit der Einzelbedienung von (bei Bedarf nichtgrafischen) Remote-Anwendungen ohne komplettes DE zu forwarden, ohne Xephyr, einfaches X-Forwarding per SSH wie in Threaderöffnung beschrieben - oder gleich mit 1 Kommando:

Code: Alles auswählen

ssh -X user@server mousepad &
ssh -X user@server xterm &
...
Eigentlich ist der Thread damit gelöst, eine grafische Lösung, die Verbindungen "auf Knopfdruck" herstellt, korrekt schließt (Displayänderung) und für künftiges Wiederherstellen speichert wäre jedoch netter. Sind wohl VNC oder RDP-Clients. Oder ein Script?! :wink:

Danke aĺlen Helfern!

Benutzeravatar
smutbert
Moderator
Beiträge: 8320
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von smutbert » 14.02.2018 00:17:38

Jana66 hat geschrieben: ↑ zum Beitrag ↑
12.02.2018 12:46:31
NAB hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 18:25:53
Jana66 hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 16:27:18
Probiere noch kurz (weil zukunftslos wegen Wayland) ein oder zwei X-Server,
X-Server werden auf Wayland weiterhin funktionieren.
Upps, ich nahm an, Wayland ersetzt künftig Xorg. Sollte ich wohl mal googeln. […]
wayland bietet mit xwayland einen eigenen X-Server, der nichts (mehr?) mit xorg zu tun hat, damit Programme laufen, die nicht nativ wayland verwenden (zum Beispiel Programme, die auf gtk2 und qt < 5 basieren) – xwayland integriert sich dabei allerdings so nahtlos, dass es fast schon ein Aufwand ist zweifelsfrei festzustellen ob man es nun mit einem wayland- oder xwayland-Fenster zu tun hat.

Deswegen sollte es auch kein Problem sein, entweder X direkt auf xwayland forzuwarden oder unter wayland Xephyr oder Xnest zu starten, genauso wie du es auch unter Xorg gemacht hast.
Schwierig wird es erst, wenn Programme irgendwann einmal nur mehr nativ unter wayland und nicht mehr als X-Clients laufen, aber bis dahin wird wohl noch einige Zeit dauern.


und zu den Fehlermeldungen:
Einige davon sind vermutlich darauf zurückzuführen, dass lokal angemeldete Benutzer von systemd-login zusätzliche Rechte erhalten, entweder durch Policykit oder durch ACLs für Gerätedateien, Dateien im sysfs, u. s. w., die bei einer remote-Anmeldung (ssh) fehlen. Das ließe sich zumindest teilweise über zusätzliche Gruppenmitgliedschaften () oder Änderungen an den PolicyKit-Regeln beheben.

Andere Meldungen liegen möglicherweise an dbus, aber das durchblicke ich nicht. Ich weiß nicht einmal ob sich X-Clients uU mit einem eventuell bereits vorhandenen dbus-daemon auf dem System mit dem X-Server läuft verbinden können oder ob das komplett undenkbar ist, wenn X-Server und -Client auf unterschiedlichen Computern laufen.

BenutzerGa4gooPh

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von BenutzerGa4gooPh » 14.02.2018 10:42:18

smutbert hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 00:17:38
wayland bietet mit xwayland einen eigenen X-Server, der nichts (mehr?) mit xorg zu tun hat, damit Programme laufen, die nicht nativ wayland verwenden ...
Ah dazugelernt. :THX:

Ich habe mal noch weiter getestet, das o. g. X-Forwarding mittels Debianxephyr ist etwas unbequem. :roll:
ThorstenS hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 07:11:41
Debianremmina kann grafisch über RDP/VNC/SSH/SFTP Verbindung zu einem entfernten Server aufnehmen. Natürlich auch über einen SSH-Tunnel. Funktioniert super bequem und RDP ist unter Linux meiner Meinung nach deutlich flotter als VNC. Auf dem entfernten [Client] Server installiere ich nochDebian xrdp und schon kann ich mir das debian mit mate auch in Vollbild nach lokal holen und fluffig flott arbeiten.
Der Unterschied zu VNC besteht hauptsächlich darin, dass damit (und mit X-Forwarding) keine Session "geshared" wird: VNC dient eher der Nutzerunterstützung (Lösung von Nutzerproblemen unter Einbeziehung dessen), RDP für Terminalsever-Sitzungen mehrerer unabhängiger Nutzer. Nachteilig empfinde ich neben dem proprietärem MS-Protokoll RDP das Öffnen eines weiteren RDP-Ports des Servers neben SSH (was man ja auch verwenden möchte) und damit ist ein weiterer Port/Dienst zu sichern! Eine Möglichkeit, per SSH ein Desktop-Environment zu forwarden, habe ich in remmina nicht gefunden. Die reine RDP-Lösung funktioniert aber gut - sicherlich dann zu priorisieren, wenn mit Windows-Clients auf (Linux-)Terminalserver zugegriffen werden soll.

Kurzanleitung für Dritte:
Client aus Backports:

Code: Alles auswählen

apt-get install -t stretch-backports remmina remmina-plugin-rdp
Server:

Code: Alles auswählen

apt-get install xrdp xorgxrdp
service xrdp status
service xorgxrdp satus
(Debianxorgxrdp bereits vorinstalliert, Debianxrdp startet per systemd, keine Konfig dazu nötig)

Code: Alles auswählen

nano /etc/X11/Xwrapper.config
ersetzen:
#allowed_users=console
allowed_users=anybody
reboot
Reboot: War zu faul rauszusuchen, welche einzelnen Services neu gestartet werden müssen. :mrgreen:
Zuletzt geändert von BenutzerGa4gooPh am 14.02.2018 11:40:02, insgesamt 5-mal geändert.

BenutzerGa4gooPh

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von BenutzerGa4gooPh » 14.02.2018 11:05:00

Zuletzt bin ich bei einer reinen X2Go-Lösung (Server und Client) "hängengeblieben":
MartinV hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 10:54:19
...neben VNC gibt es noch xpra. Als Vorteil gegenüber VNC bietet es Komprimierung und verschlüsselte Übertragung. (ok, je nach VNC-Lösung geht das auch mit VNC). Ein Frontend für xpra, VNC und noch mehr Lösungen bietet Debianx2go ...
Für die Installation des Servers findet man 2 ausgezeichnete Tuts, ich schreibe deshalb nichts dazu:
Installation: https://www.digitalocean.com/community/ ... n-debian-8 oder
https://www.tecmint.com/setup-remote-de ... in-debian/
Änderungen für Stretch: https://wiki.x2go.org/doku.php/wiki:repositories:debian

X2Go beruht auf bisher nicht standardiserter Technologie von NX Machines:
For the graphical part of remote desktop sessions, X2Go uses No Machine NX3 technology under the hood.
https://wiki.x2go.org/doku.php/doc:newtox2go
Prior to version 4.0, NoMachine used the GNU General Public License for the core NX technology, while at the same time offering non-free commercial NX solutions for the enterprise,[4] free client and server products for Linux and Solaris and free client software for Microsoft Windows, Mac OS X and embedded systems.
https://en.wikipedia.org/wiki/NX_technology

Vorteil: Nutzt SSH-Protokoll, Absicherung des entsprechenden Servers genügt.
Nachteile: Server nicht in Debian Quellen verfügbar, derzeit nicht für Gnome3 auf Server

Wer Lust hat, kann noch was zu den praktischen Unterschieden X2Go vs Debianxpra schreiben. Laut https://en.wikipedia.org/wiki/Xpra beruht das auch auf NX-Technologie und neuerdings ist Remote-Zugriff auf kompletten Desktop möglich: https://xpra.org/trac/wiki/Usage#Forwar ... oledesktop
Das Ubuntu-Wiki ist diesbezüglich wohl veraltet:
Ähnlich ist X2Go, das ebenfalls einzelne Programme entfernter Rechner ausführen kann. Der Unterschied zu Xpra besteht in der Möglichkeit, nicht nur einzelne Programme, sondern einen kompletten Desktop über das Netzwerk zu nutzen (als eigene Sitzung, nicht als geteilte wie bei VNC).
https://wiki.ubuntuusers.de/Xpra/
Debianxpra ist in den Debian-Quellen vorhanden. Ich habe nun nicht recherchierrt, ob die in Stretch enthaltene Version das Forwarding eines kompletten DE unterstützt. Und welche (alle?) DEs. Gibt ja noch Backports. :wink:
Zuletzt geändert von BenutzerGa4gooPh am 15.02.2018 16:28:40, insgesamt 1-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von MSfree » 14.02.2018 12:05:33

Jana66 hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 11:05:00
Vorteil: Nutzt SSH-Protokoll, Absicherung des entsprechenden Servers genügt.
Wenn man den VNC-Port durch SSH tunnelt, nutzt auch VNC das SSH-Protokoll. :wink:

Für den Fernwartungszugriff würde ich auch nichts anderes empfehlen.

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von MartinV » 14.02.2018 13:18:54

Jana66 hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 11:05:00
Debianxpra ist in den Debian-Quellen vorhanden. Ich habe nun nicht recherchierrt, ob die in Stretch enthaltene Version das Forwarding eines kompletten DE unterstützt. Und welche (alle?) DEs. Gibt ja noch Backports. :wink:
Die Version in stretch (xpra 0.17) ist veraltet. Inzwischen gibt es xpra 2.3. Für Desktop forwarding brauchst Du mindestens xpra 1.0, ab 2.2.1 sind einige Bugs im Desktop Modus behoben. Debian experimental bietet immerhin noch xpra 2.1.3. Ich empfehle die aktuelle Version 2.3 von der xpra Webseite.

Prinzipiell unterstützt xpra alle DEs, die auf X laufen. Gnome 3 ist auch im X-Modus problematisch, es schmeißt gerne Segfaults, wenn es nicht vom Display Manager auf echter Monitor-Hardware gestartet wird. Zudem ist es auf die GPU angewiesen (GPU ist aber machbar).

Wenn Du mit X2Go/nx zufrieden bist, ist ja soweit alles gut.
Jana66 hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 10:42:18
Ich habe mal noch weiter getestet, das o. g. X-Forwarding mittels Debianxephyr ist etwas unbequem. :roll:
Inwiefern unbequem?
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

BenutzerGa4gooPh

Re: X11-Forwarding (SSH) für komplettes Desktop Environment

Beitrag von BenutzerGa4gooPh » 14.02.2018 13:53:10

MSfree hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 12:05:33
Wenn man den VNC-Port durch SSH tunnelt, nutzt auch VNC das SSH-Protokoll.
Weiß ich doch, hab bissel recherchiert. :wink: Trotzdem ist VNC kein "native" Terminalserver. Du willst mich doch bloß vom Wechsel in ein Citrix-Forum abhalten. :mrgreen:
MartinV hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 13:18:54
Ich empfehle die aktuelle Version 2.3 von der xpra Webseite.
Prinzipiell unterstützt xpra alle DEs, die auf X laufen. Gnome 3 ist auch im X-Modus problematisch, es schmeißt gerne Segfaults, wenn es nicht vom Display Manager auf echter Monitor-Hardware gestartet wird. Zudem ist es auf die GPU angewiesen (GPU ist aber machbar).
Dann bleibe ich erst mal bei X2Go. Wenn's mich "reisst", teste ich mal unter rein praktischen Gesichtspunkten das Neueste, wie du empfiehlst. Habe ja "nur" XFCE.
MartinV hat geschrieben: ↑ zum Beitrag ↑
14.02.2018 13:18:54
Jana66 hat geschrieben: Mi 14. Feb 2018, 10:42
Ich habe mal noch weiter getestet, das o. g. X-Forwarding mittels Debianxephyr ist etwas unbequem.
Inwiefern unbequem?
Zum Einen weiß ich nicht, ob mir die oben geposten Fehler (dbus ...) mal auf die Füße fallen, zum Anderen ist der Start mit mehreren Kommandos (siehe viewtopic.php?f=2&t=168588&start=15#p1164726 ) bis zum Erreichen des Remote-DEs einschl. SSH-Verbindung und Display-Umschaltung blöd. Hatte mal erfolglos versucht, das Ubuntu-Scipt zu erweitern, startet ja nur xephyr angepasst (und da genügt mir auch ein einziges Konsolenkommando): https://wiki.ubuntuusers.de/Xephyr/Gtk-Xephyr/
Mit einem grafischen Client (X2Go oder remmina) ist das bequemer, einschließlich SSH-Verbindung und Start des DE. Speichert ja Verbindungsprofile. :wink:

Edit:
Heute "Stresstest" durchgeführt, Verbindung mit absichtlichem Flaschenhals Fast Ethernet 100 MBit/s zwischen PCs: Mit x2go kann man sogar mit dem Firefox des Remote-PCs surfen (heise.de).
Xephyr und sogar X-Forwarding mit FF als Einzelanwendung ist unertäglich zäh, auch Fehler in Fensterdarstellung. Eine beabsichtigte remote-Konfiguration des FF war kaum möglich, geschweige denn Test derer. xRDP habe ich diesbezüglich nicht getestet.

Antworten