[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

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

Beitrag von BenutzerGa4gooPh » 07.02.2018 10:16:09

Hallo Debianfreunde,

ich möchte per X11-Forwarding über SSH das DE eines 2. Rechners bedienen. Alles im eigenen LAN hinter NAT-Router/Firewall. :wink:
"Server" und Client mit Stretch, XFCE, lightdm

Die Default-SSH-Konfig des Servers habe ich vorerst belassen, wesentlich ist wohl:

Code: Alles auswählen

nano /etc/ssh/sshd_config
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
(defaults)

Code: Alles auswählen

nano /etc/ssh/ssh_config
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
(defaults)
Mit

Code: Alles auswählen

ssh -X user@hostname 
kann ich fehlerfrei verbinden,

Code: Alles auswählen

mousepad &
startet grafische Einzelanwendung fehlerfrei.

Aber:

Code: Alles auswählen

xfce4-session &
malt das "geforwardete" DE teils unter das DE des Clients (Menü, obere Leiste), teils darüber (untere Leiste mit Startern).
Fehlerausgaben:

Code: Alles auswählen

user@nuc:~$ xfce4-session &
[1] 1854
user@nuc:~$ gpg-agent[1861]: 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:1854): xfce4-session-WARNING **: gpg-agent returned no PID in the variables

(xfce4-session:1854): xfce4-session-WARNING **: xfsm_manager_load_session: Something wrong with /home/max/.cache/sessions/xfce4-session-localhost:10, Does it exist? Permissions issue?
Verbindungsfehler: Verbindung verweigert
pa_context_new() fehlgeschlagen: Verbindung verweigert
/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.78" is not allowed to own the service "com.redhat.PrinterDriversInstaller" due to security policies in the configuration file
xfsettingsd-Message: Skipping screen 0, it already has an xsettings manager...
xfwm4-Message: Another Window Manager (Xfwm4) is already running on screen localhost:10.0
xfwm4-Message: To replace the current window manager, try "--replace"

(xfwm4:1864): xfwm4-WARNING **: Could not find a screen to manage, exiting

** (xfdesktop:1872): WARNING **: xfdesktop: already running, quitting.
process 1876: 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@nuc:~$ xfsettingsd: Another clipboard manager is already running.
Versuch mit

Code: Alles auswählen

startxfce4 &
bringt noch mehr Fehler. Bei Bedarf poste ich das gern.

1. Was muss ich für korrekte Drastellung des Server-DE auf Client ändern?
2. Ist es vielleicht sinnvoll, auf dem Server ein zum Client unterschiedliches DE, unterschiedlichen Displaymanager einzusetzen? So wegen dem Über-/Untermalern.
3. Wie beendet man die grafische Session im Notfall auf Server und Client korrekt? Mit dem Klassiker kill -9 <pid von xfce4-session> habe ich mir erst mal beholfen, DE des Servers war grafisch unbedienbar.
4. Ist für mein Anliegen vielleicht VNC oder was anderes besser geeignet? Das Server-DE in einem extra Fesnter wäre "hübsch", könnte ich auf in anders virtuelles Display schieben.

Danke für's Lesen!

Edit: Das DE startete ich als user, nicht als root. Der Server wurde nur eingeschaltet, kein User angemeldet.
Zuletzt geändert von BenutzerGa4gooPh am 18.02.2018 21:47:42, insgesamt 4-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 » 07.02.2018 10:34:02

Jana66 hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 10:16:09
Aber:

Code: Alles auswählen

xfce4-session &
malt das "geforwardete" DE teils teils unter das DE des Clients
Du sollst neben mir keine anderen Windowmanager haben. :mrgreen:

Deine Idee, das mit VNC zu realisieren, ist eine Möglichkeit.

Du müßtest dazu auf dem Server einen VNC-Server installieren. Bei mir ist das so eingerichtet, daß beim Start des Displaymanagers (kdm) zwei X-Server bedient werden, der physikalische X-Server und der VNC-X-Server, auf beiden bekommen ich den graphischen Login. Das ganze läuft allerdings noch auf Jessie, zu Stretch kann ich diesbezüglich noch nichts beitragen.

Vom Client kann ich dann per vncviewer auf den Server zugreifen, mich einloggen, was in Folge die Desktopsession dort startet, inklusive des Windowmanagers.

Bei mir funktioniert das mti KDE recht brauchbar. Gnome funktioniert so allerdings gar nicht, dazu gab es hier auch schonmal einen Thread. Mit den meisten Windowmanagern von IceWM über XFCE bis zu KDE sollte es aber keine Probleme geben.

BenutzerGa4gooPh

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

Beitrag von BenutzerGa4gooPh » 07.02.2018 10:47:31

MSfree hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 10:34:02
Deine Idee, das mit VNC zu realisieren, ist eine Möglichkeit.
Mache ich, wenn's Linux native (X11-Forwarding) nicht sinnvoll klappt. Hast's wohl auch nicht hingekriegt? :mrgreen:
(Also ich erinnere mich dunkel an meine ersten UNIX-Erfahrungen mit 'ner Sun (Solaris?) (etwa 1996/97): Telnet und irgendeine Displayumleitung für Remote-Zugriff auf andere, 2 Kommandos. Damals war das Internet noch relativ sicher, maximal Paketfilter anstelle SPI-Firewall ... und Netscape-Browser. Die GUI der Sun war ähnlich LXDE.)
Zuletzt geändert von BenutzerGa4gooPh am 07.02.2018 10:54:53, insgesamt 1-mal geändert.

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 » 07.02.2018 10:54:19

Hallo Jana,

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.

Ich bin mit xpra eher für lokale Setups vertraut, nicht über Netzwerk. Es sollte etwa so gehen:

Code: Alles auswählen

# xpra server auf entferntem Rechner starten
xpra start-desktop ssh:HOSTNAME:30 --start-via-proxy=no --start-child=xfce4-session --exit-with-children=yes
# Mit xpra server verbinden
xpra attach ssh:HOSTNAME:30
Trennen und wieder Verbinden geht auch, ohne daß xfce beendet wird (im Unterschied zu normalem "ssh -X", das bei Verbindungstrennung die Anwendungen beendet):

Code: Alles auswählen

# Trennen
xpra detach ssh:HOSTNAME:30
# erneut verbinden:
xpra attach ssh:HOSTNAME:30
xpra server beendet sich durch "--start-child=xfce4-session --exit-with-children=yes" selbst, wenn xfce beendet wird. Manuell geht es mit:

Code: Alles auswählen

xpra stop ssh:HOSTNAME:30

xpra muß dafür auf beiden Rechnern installiert sein.
Zuletzt geändert von MartinV am 07.02.2018 17:39:06, insgesamt 1-mal geändert.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

uname
Beiträge: 12044
Registriert: 03.06.2008 09:33:02

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

Beitrag von uname » 07.02.2018 11:13:45

Jana66 hat geschrieben: ... ersten UNIX-Erfahrungen mit 'ner Sun (Solaris?) (etwa 1996/97) ...
Es gibt noch die Möglichkeit von "xhost +" (Client) und "export DISPLAY=...:0.0" (Server). Besser ist das auch nicht.

Damals war es so, dass man nur die benötigten Anwendungen exportiert hat. Textbasierte Anwendungen wie Editoren (Vim, Compiler, mc, ...) hat man gleich im Terminal (ssh-Sitzung evtl. in Verbindung mit Screen) bedient und nicht exportiert. Und wenn es mal nötig war vielleicht mal eine grafische Entwicklungsumgebung. Niemand wäre damals auf die Idee gekommen von einer Sun einen graphischen Dateimanager (gab es das?), den Browser, den Editor geschweige denn das gesamte Desktop-Environment zu übernehmen. Auch hat man die Laufwerke der Sun per NFS gemountet und lokal identische Anwendungen (grafischer Editor) verwendet. Also schau dir lieber mal Debiansshfs, Debianmc, Debianvim, Debianscreen, Debiantmux usw. an und minimiere die Anzahl der benötigten exportierten graphischen Anwendungen. Alternativ verwende die oben geannten Lösungen, die mit dem UNIX/Linux-Gedanken wenig zu tun haben.

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

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

Beitrag von MSfree » 07.02.2018 11:25:36

Jana66 hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 10:47:31
Mache ich, wenn's Linux native (X11-Forwarding) nicht sinnvoll klappt. Hast's wohl auch nicht hingekriegt? :mrgreen:
X11-Forwarding klappt ja, es ist aber für einzelne Clients gedacht und nicht für ein komplettes Desktop Environment (AKA Windowmanager). Du kannst nach dem SSH-Login ja ganz problemlos z.B. xterm oder xclock starten und die kommen ganz brav in deiner Session an, gemanaged werden die dann vom lokalen Windowmanager.

Wenn du einen kompletten Desktop übertragen willst, ist X11-Forwarding nicht das geeignete Mittel, weil dann zwei Windowmanager bzw. Desktopsessions (die lokale und die remote) konkurrieren.

uname
Beiträge: 12044
Registriert: 03.06.2008 09:33:02

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

Beitrag von uname » 07.02.2018 12:20:32

Vielleicht kannst du es ja mit VNC mit XDMCP realisieren:

https://debian-handbook.info/browse/de- ... login.html

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 07.02.2018 17:22:55

Jana66 hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 10:47:31
Mache ich, wenn's Linux native (X11-Forwarding) nicht sinnvoll klappt. Hast's wohl auch nicht hingekriegt? :mrgreen:
Das "native X11 forwarding" nennt sich XDMCP und klappt hier hervorragend:
https://wiki.archlinux.org/index.php/Xdmcp#LightDM

Zugriff dann z.B. mit:

Code: Alles auswählen

Xephyr -query 192.168.0.1 -keybd ephyr,,,xkbmodel=pc105,xkblayout=de,xkbrules=evdev,xkboption=grp:alts_toogle -ac -br -reset -terminate -screen 1280x768 :1
(Dass man 192.168.0.1 dann hinter einer dicken Firewall im LAN haben möchte, erwähne ich nur für die unbedarften Mitleser)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

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

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

Beitrag von smutbert » 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.
Als Ausgangspunkt startes du xnest/xephyr entweder ohne WM mit einem xterm als Client oder du startest direkt ssh mit der Xfce-Sitzung als Client

Analog dazu funktioniert es auch bei der Anmeldung auf dem lokalen System eine Art Notfall- oder Minimalsitzung auszuwählen, die es zumindest früher meistens gegeben hat.
Damit wird (wurde) xterm ohne Fenstermanager gestartet und von dort aus lässt sich über ssh die Verbindung aufbauen und remote eine komplette Xfce-Sitzung oder ähnliches starten.
Fehlt diese Notfallsitzung (ich weiß nicht ob das eine Funktion des jeweiligen Displaymanagers war oder ob die Teil irgendeines Pakets war, das ich jetzt nicht mehr finde), dann sollte sie sich leicht mit einer neuen .desktop-Datei in »/usr/share/xsessions/« nachrüsten lassen (hoffentlich stimmt das für lightdm überhaupt, aber wenn dann könnte man so auch direkt den ssh-Befehl als Sitzung starten lassen).


Obwohl mir grundsätzlich X-Forwarding sympathischer wäre, würde ich, weil es mit den meisten aktuellen Anwendungen und vermutlich erst recht Desktopumgebungen flüssiger läuft und wegen Wayland eher auf vnc, xpra oder ähnliches setzen.

Recht komfortabel scheint mir die Variante auf dem Remotesystem lightdm mit einem vnc-Server, der gleichzeitig als X-Server fungiert, laufen zu lassen. Dann bekommt man mit einem vnc-Client den Anmeldebildschirm auf den lokalen Computer oder bei automatischer Anmeldung im entfernten lightdm direkt die grafische Sitzung: viewtopic.php?f=32&t=155933

Wie das gemeint ist…
uname hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 12:20:32
Vielleicht kannst du es ja mit VNC mit XDMCP realisieren:

https://debian-handbook.info/browse/de- ... login.html
...würde mich allerdings interessieren. Was hat XDMCP mit VNC zu tun bzw. wie lassen sich die beiden kombinieren?

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 » 08.02.2018 00:57:02

smutbert hat geschrieben: ↑ zum Beitrag ↑
08.02.2018 00:14:52
Analog dazu funktioniert es auch bei der Anmeldung auf dem lokalen System eine Art Notfall- oder Minimalsitzung auszuwählen, die es zumindest früher meistens gegeben hat.
Damit wird (wurde) xterm ohne Fenstermanager gestartet und von dort aus lässt sich über ssh die Verbindung aufbauen und remote eine komplette Xfce-Sitzung oder ähnliches starten.
Diese "Notfallsitzung" (nacktes X mit xterm ohne Fenstermanager) wird von xinit erzeugt, wenn es keine .xinitrc gibt und es keine Parameter bekommt.
xinit kann man auch mit Xephyr nutzen und eine eigene xinitrc angeben.

Beispiel für eine ~/xinitrc-ssh:

Code: Alles auswählen

#! /bin/sh
ssh -X jana@fernerserver
Xephyr starten mit:

Code: Alles auswählen

xinit ~/xinitrc-ssh -- /usr/bin/Xephyr :1
Alternativ kannst Du auch auf eine Konsole wechseln und ein zweites Xorg statt Xephyr starten: (vt2 auf tty2. vt6 auf tty6 usw.)

Code: Alles auswählen

xinit ~/xinitrc-ssh -- /usr/bin/X :2 vt2
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

BenutzerGa4gooPh

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

Beitrag von BenutzerGa4gooPh » 08.02.2018 17:18:16

Herzlichen Dank für die vielen Vorschläge. Paar probiere ich mal aus.

Ich habe als erstes den Vorschlag von smutbert und MartinV aufgegriffen, lokales System:
Datei ~/xinitrc-ssh erstellt, ausführbar gemacht, Inhalt wie MartinV schrieb, user@server angepasst.
STRG+ALT+F2 und Versuch, X-Server zu starten mit letztem Kommando von MartinV: Blackscreen, kein Absturz, irgendwas ist gestartet, VT7 erreichbar.
(Virtuelles Terminal ohne Grafik sollte doch auch eine Notfallsitzung ohne alles sein, ein Start im normalen xfce-terminal war auch nicht möglich. Oder habe ich falsch verstanden?)

Dann habe ich versucht, einen 2. XServer in VT2 zu starten:

Code: Alles auswählen

startx -display :2 -- :2 vt2 &
Kleines weißes Fenster und ich kann per SSH-X-Forwarding die xfce4-session "rüberholen". Gut, paar kleine Schönheitsfehler im DE, Fehlermeldungen beim Start wie oben gepostet - aber bedienbar.

Problem hierbei: Der ursprüngliche X-Server in VT7 beendet sich wohl, Anmeldefenster erscheint nach Umschalten auf VT7, Firefox "entschuldigt" sich nach Anmeldung wegen Absturz nach Login.

Werde mal xnest/xephyr testen. Aber irgendwie muss das doch mit einem zweiten X-Server auch gehen.
smutbert hat geschrieben: ↑ zum Beitrag ↑
08.02.2018 00:14:52
Obwohl mir grundsätzlich X-Forwarding sympathischer wäre, würde ich, weil es mit den meisten aktuellen Anwendungen und vermutlich erst recht Desktopumgebungen flüssiger läuft und wegen Wayland eher auf vnc, xpra oder ähnliches setzen.
Da hast du wohl Recht. Ich mache noch Versuche mit den vorgeschlagenen Servern, dann VNC.
NAB hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 17:22:55
Das "native X11 forwarding" nennt sich XDMCP und klappt hier hervorragend:
https://wiki.archlinux.org/index.php/Xdmcp#LightDM
Leider ohne SSH. Mein Serverlein hat WLAN, da ist mir Verschlüsselung und nur 1 lauschender Port für Management lieber.
uname hat geschrieben: ↑ zum Beitrag ↑
07.02.2018 11:13:45
Also schau dir lieber mal sshfs, mc, vim, screen, tmux usw. an und minimiere die Anzahl der benötigten exportierten graphischen Anwendungen.
Das werde ich tun, Debianscreen und Debianmc gefallen mir schon mal. Das X-Forwarding nur für "Bequemlichkeitsnotfall" und als Studienobjekt. Na ja, VNC gehört wohl schon zur Allgemeinbildung?!

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

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

Beitrag von ThorstenS » 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 installiere ich noch Debianxrdp und schon kann ich mir das debian mit mate auch in Vollbild nach lokal holen und fluffig flott arbeiten.
Selbst Windowserver habe ich dort mittlerweile hinterlegt. remmina ist eins meiner Lieblings-X-Programme.

BTW:
Die Zeiten als die Azubis mit xhost + ihre Maschinen geöffnet haben, waren lustig. Und xeyes war das harmloseste, was da plötzlich aufgetaucht ist :mrgreen:

Edith:
danke für den Hinweis, xpra ist echt nett!

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 » 09.02.2018 14:54:35

Jana66 hat geschrieben: ↑ zum Beitrag ↑
08.02.2018 17:18:16
Datei ~/xinitrc-ssh erstellt, ausführbar gemacht, Inhalt wie MartinV schrieb, user@server angepasst.
STRG+ALT+F2 und Versuch, X-Server zu starten mit letztem Kommando von MartinV: Blackscreen, kein Absturz, irgendwas ist gestartet, VT7 erreichbar.
(Virtuelles Terminal ohne Grafik sollte doch auch eine Notfallsitzung ohne alles sein, ein Start im normalen xfce-terminal war auch nicht möglich. Oder habe ich falsch verstanden?)
Hmm, ich vermute gerade, der SSH Befehl will eine Paßwortabfrage durchführen, im leeren X hast Du aber keine Eingabemöglichkeit. Dafür müßte SSH paßwortlos konfiguriert werden.
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

#! /bin/sh
xterm -e ssh -X user@servername
Von startx rate ich ab, es macht alles mögliche und ist etwas unüberschaubar. Bei xinit hast Du mehr Kontrolle über das, was passiert.
Jana66 hat geschrieben: ↑ zum Beitrag ↑
08.02.2018 17:18:16
~/xinitrc-ssh erstellt, ausführbar gemacht,
Ausführbar machen ist nicht nötig, um die Ausführung kümmert sich xinit. Das #!/bin/sh ist eigtl. unnötig, ich schreibe es nur immer dabei, um mich selbst daran zu erinnern, daß xinitrc keine bash-Extras versteht.

Den X Aufruf kann man noch optimieren, sinnvoll ist wahrscheinlich -dpms, um Energiesparmodi abzuschalten. Früher war "-nolisten tcp" wichtig, ist aber, glaube ich, inzwischen default. Zu Überlegen wäre noch das Erstellen eines Cookies. Aber erst einmal sollte es funktionieren, danach kann man es besser machen.

Vorsicht, Werbung: Du kannst das ganze X Gedöns x11docker überlassen, über Optionen ( --xephyr, --xpra, --xorg, ...) stehen Dir verschiedene X Server zur Verfügung:

Code: Alles auswählen

x11docker --desktop --exe -- xterm -e ssh -X user@servername
Oder kürzer:

Code: Alles auswählen

x11docker -de -- xterm -e ssh -X user@servername
Zuletzt geändert von MartinV am 09.02.2018 16:31:57, insgesamt 1-mal geändert.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

BenutzerGa4gooPh

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

Beitrag von BenutzerGa4gooPh » 09.02.2018 16:27:18

ThorstenS hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 07:11:41
... xrdp und schon kann ich mir das debian mit mate auch in Vollbild nach lokal holen und fluffig flott arbeiten.
Danke auch dir! Als Linuxine mag ich wohlfunktionierende, aber proprietäre Protokolle nur nutzen, wenn's nicht anders geht. :wink:
MartinV hat geschrieben: ↑ zum Beitrag ↑
09.02.2018 14:54:35
Hmm, ich vermute gerade ...
Kann erst Montag weiter machen. Probiere noch kurz (weil zukunftslos wegen Wayland) ein oder zwei X-Server, ansonsten geht's mit VNC (ueber SSH) als Quasistandard weiter. Ein funktionierender zweiter X-Server wird die oben geposteten Fehler beim Starten der Remote-Session eh nicht verhindern, also nur "akademisches Interesse". Schönes WE dir und allen Foristen!

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von NAB » 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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

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: 8314
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