Remote Desktop mit X?

[Kay Martinen]

Hallo

Ich erinnere mich gelesen zu haben das es bei modernen Linuxen zunehmend
ein Problem wäre was früher allgemein möglich gewesen sein soll. Das
lokale Starten eines X-Servers und die Verbindung mit einem Remote Host
um von Programmen die dort laufen sollen die Ein-/Aus-gabe auf dem
eigenen X-Server zu erledigen.

So weit die Theorie. Aber an was genau hapert es da eigentlich wirklich
und ist das nur bei bestimmten Programmen so oder ein
Generelles/Konzeptionelles umdenken (z.b. weil es Teamviewer o.a. ja
auch für Linux gibt)?

Ich las mal das der Remote Login bei Login-Managern üblicherweise
ausgeschaltet ist - der Sicherheit wegen. Also kann man ihn aktivieren
oder? Damit sollte dann eine X Session auf dem Remote Host starten,
nehme ich an. Dann müsste man DISPLAY auf den eigenen/Lokalen X-Server
setzen wenn ich richtig erinnere. Und alle ab dann gestarteten Programme
sollten IO auf meinem Host erledigen, liefen aber weiterhin auf dem
Entfernten Host.

Trifft das dann auch auf Sachen zu wie Firefox und Thunderbird (auch
64-Bit Version) ebenso wie eine Konsole oder einen Dateimanager wie Dolphin?

In wie fern ist das vom Desktop abhängig, z.b. KDE oder Gnome und wie
sie sonst alle heißen?

Ich vermute lediglich das bei Grafikintensiveren Sachen die
Netzwerk-Bandbreite (LAN) limitierend würde. Z.b. beim Film sehen mit
VLC oder Videoschnitt mit DVBCut oder auch nur einem youtube-Video sehen
und/oder Downloaden.

Wie man dabei den Ton mit umleitet, vom Remote Host auf den lokalen und
dort dann z.b. auf Soundkarte und/oder HDMI ausgabe kann ich mir grad
nicht mal vorstellen.

Geht irgendwas davon einfach so, im Handumdrehen und ohne Großes
Gefrickel so als würde man eine Teamviewer Sitzung aufbauen?

Bei einem Debian 8 habe ich mal eine "Desktop-Freigabe" probiert die
integriert war und leicht zu nutzen war. Aber nicht auf dauer. Nicht wie
eine gespeicherte RDC-Sitzung die man per Doppelklick aufruft und dann
bestenfalls noch das Kennwort eingeben muß. Windows-Only! Denn die Tools
um das gleiche für Linux zu ermöglichen schienen mir damals auch nicht
sehr stabil oder leicht ein zu richten. Das gleiche Traf auf VNC zu.

Hat Windows in dem Bereich einfach die Nase vorn oder gibt es eine
Einfache und kostenfreie (OpenSource?) Lösung die mit jedem Desktop
funktioniert?

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:

> Ich erinnere mich gelesen zu haben das es bei modernen Linuxen zunehmend
> ein Problem wäre was früher allgemein möglich gewesen sein soll. Das
> lokale Starten eines X-Servers und die Verbindung mit einem Remote Host
> um von Programmen die dort laufen sollen die Ein-/Aus-gabe auf dem
> eigenen X-Server zu erledigen.

Das nannte sich X-Terminal, nicht zu verwechseln mit xterm.
Ersteres ist Hardware, zweiteres Software.

> So weit die Theorie. Aber an was genau hapert es da eigentlich wirklich

An Security. Die Verbindung ist unverschluesselt und kann mitgelesen werden.
Das ist einer der Gruende warum X-Terminals ausgestorben sind. Der andere
ist, dass Linux-PCs billig(er) geworden sind.

> Ich las mal das der Remote Login bei Login-Managern üblicherweise
> ausgeschaltet ist - der Sicherheit wegen. Also kann man ihn aktivieren
> oder? Damit sollte dann eine X Session auf dem Remote Host starten,
> nehme ich an. Dann müsste man DISPLAY auf den eigenen/Lokalen X-Server
> setzen wenn ich richtig erinnere. Und alle ab dann gestarteten Programme
> sollten IO auf meinem Host erledigen, liefen aber weiterhin auf dem
> Entfernten Host.

Du beschreibst das Prinzip eines X-Terminals :-)

> Trifft das dann auch auf Sachen zu wie Firefox und Thunderbird (auch
> 64-Bit Version) ebenso wie eine Konsole oder einen Dateimanager wie Dolphin?

Das sind alles X-Clients (Software). Welche das sind ist dem X-Server egal.

> In wie fern ist das vom Desktop abhängig, z.b. KDE oder Gnome und wie
> sie sonst alle heißen?

Gar nicht.

> Ich vermute lediglich das bei Grafikintensiveren Sachen die
> Netzwerk-Bandbreite (LAN) limitierend würde. Z.b. beim Film sehen mit
> VLC oder Videoschnitt mit DVBCut oder auch nur einem youtube-Video sehen
> und/oder Downloaden.

Das X11 Protokoll uebertraegt nur Video, kein Audio.

> Wie man dabei den Ton mit umleitet, vom Remote Host auf den lokalen und
> dort dann z.b. auf Soundkarte und/oder HDMI ausgabe kann ich mir grad
> nicht mal vorstellen.

Geht nicht.

> Hat Windows in dem Bereich einfach die Nase vorn oder gibt es eine
> Einfache und kostenfreie (OpenSource?) Lösung die mit jedem Desktop
> funktioniert?

Video UND Audio? Nein.

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Christian Weisgerber]

On 2022-11-17, Kay Martinen <use...@martinen.de> wrote:

> Ich erinnere mich gelesen zu haben das es bei modernen Linuxen zunehmend
> ein Problem wäre was früher allgemein möglich gewesen sein soll. Das
> lokale Starten eines X-Servers und die Verbindung mit einem Remote Host
> um von Programmen die dort laufen sollen die Ein-/Aus-gabe auf dem
> eigenen X-Server zu erledigen.

So um 1990 herum war es z.B. an Universitäten üblich, dass die
Anwender vor X-Terminals saßen, also Endgeräte die nur die Eingabe
mit Tastatur/Maus und die grafische X11-Ausgabe übernommen haben,
und sich mit diesen Terminals über das 10-Mbit/s-Ethernet in Rechnern
eingeloggt haben, auf denen alle Anwendungen liefen. X11 ist genau
dafür ausgelegt.

Auf dem Zielrechner musste dazu ein entsprechend konfigurierter
xdm(1) laufen.

Ein solches Terminal konnte man nachbilden, indem man den X11-Server
von einem entsprechend konfigurierten xdm(1) starten lässt, der
entweder direkt eine Verbindung zu einem bestimmten Zielhost herstellt
oder einen Chooser anbietet, mit dem der Anwender aus einer List
verfügbarer Zielhosts auswählen kann.

Ich habe solche Konfigurationen früher mehrfach eingerichtet, die
Details aber weitgehend vergessen. Irgendwann hat das mit Chooser
wegen Bugs in xdm nicht mehr funktioniert; ich glaube als 64-Bit-Rechner
auftauchten.

Eine kleinere Variante, die ich noch länger verwendet habe, ist
dass die X11-Sitzung auf dem lokalen Rechner läuft, aber man
(seinerzeit mit rlogin/rsh, heute ssh) auf einem fernen Host ein
X11-Programm startet und mit Setzen der DISPLAY-Variable die Ausgabe
zum lokalen X11-Server leitet. Dazu kommt dann noch das Thema
Authentisierung mit xhost(1), xauth(1).

Heutzutage verwendet man statt dieser kleineren Variante einfach
das X11-Forwarding von ssh(1).

> So weit die Theorie. Aber an was genau hapert es da eigentlich wirklich

Daran, dass es niemand mehr verwendet. Wer weiß, wie weit der Bit Rot
(Softwareerosion) inzwischen fortgeschritten ist.

Ein technisches Problem mag sein, dass manche Programme oder Toolkits
die Grafik nicht mehr mit den Primitives des X11-Protokols aufbauen
wollen, die übers Netzwerk übertragen werden können, sondern über
libdrm direkt in den Grafikspeicher schreiben wollen. Keine Ahnung,
inwieweit das inzwischen ein praktisches Problem ist. Kann man
einfach damit testen, ob das Programm mit SSH-X11-Forwarding
funktioniert.

> Wie man dabei den Ton mit umleitet, vom Remote Host auf den lokalen und
> dort dann z.b. auf Soundkarte und/oder HDMI ausgabe kann ich mir grad
> nicht mal vorstellen.

Eigene Protokolle, wofür es im Laufe der Jahre mehr gab, als meine
Erinnerung auf Abruf liefern kann. KDE hatte aRts, GNOME hatte
EsounD. Programme müssen halt für die Audioausgabe ein entsprechendes
Audiosystem unterstützen, dass das kann. PulseAudio kann es. Das
ungleich einfachere sndio auch, das verwende ich nämlich sporadisch.

Eine Zeitlang habe ich Musik gehört mit XMMS, das auf Rechner 1
lief, dessen grafische Ausgabe aber zum X11-Server auf Rechner 2
ging und die Audioausgabe zu Rechner 3 mit der Soundkarte.

> Geht irgendwas davon einfach so, im Handumdrehen und ohne Großes
> Gefrickel

Vermutlich nicht, weil es kein üblicher Aufbau mehr ist. Was ironisch
ist, weil wie gesagt X11 genau dafür konzipiert wurde.

Nochwas: Die ganze X11-Netzwerkfunktionalität geht von einem
freundlichen Netz aus, wo niemand lauscht oder gar manipuliert.
Schutzmechanismen gibt es keine. (Man kann natürlich IPsec unterziehen.)

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Andreas Kohlbach]

On Thu, 17 Nov 2022 21:42:59 +0100, Kay Martinen wrote:
>
> Hallo
>
> Ich erinnere mich gelesen zu haben das es bei modernen Linuxen
> zunehmend ein Problem wäre was früher allgemein möglich gewesen sein
> soll. Das lokale Starten eines X-Servers und die Verbindung mit einem
> Remote Host um von Programmen die dort laufen sollen die Ein-/Aus-gabe
> auf dem eigenen X-Server zu erledigen.
>
> So weit die Theorie. Aber an was genau hapert es da eigentlich
> wirklich und ist das nur bei bestimmten Programmen so oder ein
> Generelles/Konzeptionelles umdenken (z.b. weil es Teamviewer o.a. ja
> auch für Linux gibt)?
>
> Ich las mal das der Remote Login bei Login-Managern üblicherweise
> ausgeschaltet ist - der Sicherheit wegen. Also kann man ihn aktivieren
> oder? Damit sollte dann eine X Session auf dem Remote Host starten,
> nehme ich an. Dann müsste man DISPLAY auf den eigenen/Lokalen X-Server
> setzen wenn ich richtig erinnere. Und alle ab dann gestarteten
> Programme sollten IO auf meinem Host erledigen, liefen aber weiterhin
> auf dem Entfernten Host.

[Und viel mehr]

Ich mache es mal ganz kurz, und auf die Gefahr hin, Wesentliches
missverstanden zu haben.

Hast Du im internen Netz einen weiteren Linux-Rechner? Dann versuche
einfach mal

ssh -X 192.168.0.101 firefox

in der Annahme, dass das seine IP ist. Nach einigen Warnungen sollte auf
dem lokalen Rechner der entfernte Firefox starten.

Das geht auch, ohne dass X (oder auch nur GDM, KDM, XDM...) läuft.

Am entfernten Rechner muss natürlich ein SSHD laufen, und X erlaubt
haben, was IIRC zumindest bei Debian der Fall ist.
--
Andreas

[Jan Novak]

Am 18.11.22 um 02:57 schrieb Andreas Kohlbach:

> [Und viel mehr]
>
> Ich mache es mal ganz kurz, und auf die Gefahr hin, Wesentliches
> missverstanden zu haben.
>
> Hast Du im internen Netz einen weiteren Linux-Rechner? Dann versuche
> einfach mal
>
> ssh -X 192.168.0.101 firefox

Ich hörte zwar davon, das es geht. Aber dass es so einfach geht. Ich bin
Überrascht. das ist ja cool :-)


Jan

[Diedrich Ehlerding]

Kay Martinen meinte:

> Ich erinnere mich gelesen zu haben das es bei modernen Linuxen
> zunehmend ein Problem wäre was früher allgemein möglich gewesen sein
> soll. Das lokale Starten eines X-Servers und die Verbindung mit einem
> Remote Host um von Programmen die dort laufen sollen die Ein-/Aus-gabe
> auf dem eigenen X-Server zu erledigen.

Ja. Ausprobieren zB mit

- lokaler X-server starten, darin lokales xterm. Zum Beispiel auch auf
einem Windows-Rechner ein cygwin-X11, oder ein exceed
(wenn man für letzteres die Lizenz hat).

- im xterm, also aus der lokalen grafischen Session heraus,
"ssh -X ${ferne_UserID}@${fernes_System}" oder "ssh -Y ..."
(den Unterschied habe ich noch nicht genau verstanden). Dazu muss
auf dem fernen System der sshd X11-forwarding erlauben
(/etc/ssh/sshd-config ggf anpassen, sshd restarten)

- xeyes oder ein ähnliches Programm auf dem fernen system starten

oder auf dem lokalen Rechner im xterm "xhost +" (oder besser die
erlaubtebn Clients näher spezifizieren) und auf dem fernen Rechner
"export DISPLAY=${lokaler_Rechner}:0.0" (bzw. nach dem Rechnernamen das,
was lokal in "echo $DISPLAY" steht und dann dort ein Grafikprogramm
starten.

Es empfiehlt sich sehr, wenn für alle beteiligten Systeme die
Namensauflösung vorwärts und rückwärts funktioniert (entweder/besser per
DNS, oder in /etc/hosts).


> So weit die Theorie.

Auch die Praxis, ...

> Aber an was genau hapert es da eigentlich
> wirklich

... es sei denn, die beteiligten Rechner nutzten Wayland statt X.org

> Ich las mal das der Remote Login bei Login-Managern üblicherweise
> ausgeschaltet ist - der Sicherheit wegen. Also kann man ihn aktivieren
> oder?

Ja, schau mal in die Konfiguration des Login-Managers auf dem fernen
System (je nach Login-Manager) und suche dort nach dem stichwort
"XDMCP". Oder nutze das entsprechende Admin-Tool deiner Distribution
(also der Distribution des fernen Systems), um XDMCP anzuschalten.

> Damit sollte dann eine X Session auf dem Remote Host starten,
> nehme ich an.

Vorgehensweise: auf dem lokalen Rechner, der im Nicht-Grafik-Modus
läuft, also vorher ohne X11, "X -query ${ferner_Rechner}" eingeben. Dann
sollte eione grafische Login-Maske des fernen systems auftauzchen, da
kannst du dich einloggen und bekommst einen Desktop des fernen Systems.
Das habe ich allerdings nur vor ziemlich langer Zeit mal gemacht (mit
cygwin-X auf Windows und einem Solaris-Zielsystem, an dem damals remote
X-Login noch offen war).

Damit bekommst du dann nach dem Login einen kompletten Desktop (also den
Windowmanager des entfernten Systems), ganz egal was du lokal für einen
Desktop verwendest. Im Fall "ssh -Y" startest du im Gegensatz dazu ein
einzelnes grafisches Programm, dessen Fensterdekorationen, Mausknöpfe
usw. von deinem lokalen Windowmanager stammen; ggf. also auch von
Windows, wenn du lokal ein Windows hast.

> Trifft das dann auch auf Sachen zu wie Firefox und Thunderbird (auch
> 64-Bit Version) ebenso wie eine Konsole oder einen Dateimanager wie
> Dolphin?

Das funktioniert auch mit firefox etc. Been there, done that (vor vielen
Jahren sogar über eine ISDN-Leitung zu einem Kunden, das war natürlich
schnarchlangsam, aber immer noch besser als einen Tag Anreise und einen
Tag Abreise).

>
> In wie fern ist das vom Desktop abhängig, z.b. KDE oder Gnome und wie
> sie sonst alle heißen?

Wie gesagt, wenn da ein Wayland im Spiel ist, sieht es nicht gut aus.

Der ferne Desktop kommt nur ins Spiel beim X -query. Im Falle ssh oder
im Fall der xhost +/export DISPLAY-Methode hast du deinen lokalen
Desktop und siehst nur das Fenster des Programms. Im Zweifel erkennst du
kaum einen Unterschied zwischen einem lokalen und einem fernen Firefox.

>
> Ich vermute lediglich das bei Grafikintensiveren Sachen die
> Netzwerk-Bandbreite (LAN) limitierend würde.

Ja, und die Latenz. Im Heimnetz, also um einen im Keller stehenden
Fileserver grafisch zu managen, ohne runtergehen zu müssen, sollte das
problemlos gehen,

> Z.b. beim Film sehen mit
> VLC oder Videoschnitt mit DVBCut oder auch nur einem youtube-Video
> sehen und/oder Downloaden.

Ja, Videos könnten hakelig sein, 3D-Grafikspiele (tuxracer, flightgear
etc) auch. Und wenn du in einem auf dem fernen Rechner gestarteten
Firefox etwas downlädst, dann landet das natürlich im Download-
Verzeichnis des fernen Rechners, nicht auf deinem PC.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Ulli Horlacher]

Guten Morgen :-)
Das funktioniert seit gut 30 Jahren so.
Mit telnet/rsh sogar schon deutlich laenger. Auch auf nicht-UNIX-Systemen.

[Jan Novak]

Am 18.11.22 um 13:01 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 18.11.22 um 02:57 schrieb Andreas Kohlbach:
>>> [Und viel mehr]
>>>
>>> Ich mache es mal ganz kurz, und auf die Gefahr hin, Wesentliches
>>> missverstanden zu haben.
>>>
>>> Hast Du im internen Netz einen weiteren Linux-Rechner? Dann versuche
>>> einfach mal
>>>
>>> ssh -X 192.168.0.101 firefox
>>
>> Ich hörte zwar davon, das es geht. Aber dass es so einfach geht. Ich bin
>> Überrascht. das ist ja cool :-)
>
> Guten Morgen :-)
> Das funktioniert seit gut 30 Jahren so.
> Mit telnet/rsh sogar schon deutlich laenger. Auch auf nicht-UNIX-Systemen.
>

Ich wusste schon, dass es x11 forwarding gibt. Da ich mich nie damit
beschäftigt habe ... sei's drum.

Was mir aber gerade auffiel: Auf dem entferntem Client lief bereits
Chrome. Als ich es mit ssh -X ausführte, hat er ein neues Fenster auf
dem entfernten Client geöffnet, nicht aber auf meinem Client.

Jan

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:

> Was mir aber gerade auffiel: Auf dem entferntem Client lief bereits
> Chrome. Als ich es mit ssh -X ausführte, hat er ein neues Fenster auf
> dem entfernten Client geöffnet, nicht aber auf meinem Client.

Windoof-Programmierer gibts auch bei Google.

[Marc SCHAEFER]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Was mir aber gerade auffiel: Auf dem entferntem Client lief bereits
>> Chrome. Als ich es mit ssh -X ausführte, hat er ein neues Fenster auf
>> dem entfernten Client geöffnet, nicht aber auf meinem Client.
>
> Windoof-Programmierer gibts auch bei Google.

Das Problem besteht wahrscheinlich auch bei Firefox: das Problem, ist
das "firefox&" wird einfach mit dem schon gestarteten Chrom oder Firefox
Programm kommunizieren, ohne DISPLAY beim anderen Prozess ändern zu können.

Eine Frage noch: unterstützt Wyland ssh -X jetzt?

[Ralph Angenendt]

Well, Marc SCHAEFER <scha...@alphanet.ch> wrote:

> Eine Frage noch: unterstützt Wyland ssh -X jetzt?

Es gibt waypipe <https://gitlab.freedesktop.org/mstoeckl/waypipe>, ich
weiß aber nur, dass es existiert, ich habe noch nicht damit gearbeitet.

Ralph
--
Is your mother worried?
Would you like us to assign someone to worry your mother?

[Ulli Horlacher]

So was machen nur DOOFe, wenn $DISPLAY was anderes als :0 ist!
"Alles ist ein PC!"

[Christian Weisgerber]

On 2022-11-17, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Das nannte sich X-Terminal, nicht zu verwechseln mit xterm.

An der Uni Kaiserslautern haben wir die Geräte deshalb als
"X-Display" bezeichnet. Dieser Sprachgebrauch hat sich leider
nicht durchgesetzt.

> Das X11 Protokoll uebertraegt nur Video, kein Audio.

Man braucht halt ein separates Audioprotokoll. Von NCD gab es
offenbar X-Terminals mit Unterstützung für NAS (Network Audio
System):
https://radscan.com/nas.html

[Marc SCHAEFER]

Christian Weisgerber <na...@mips.inka.de> wrote:
>> Das X11 Protokoll uebertraegt nur Video, kein Audio.
>
> Man braucht halt ein separates Audioprotokoll. Von NCD gab es
> offenbar X-Terminals mit Unterstützung für NAS (Network Audio
> System):
> https://radscan.com/nas.html

Sonst gibt's x2go. Audio, Drücken, Filesharing. Kann man auch als
"screen" oder "tmux" benutzen (mehrere Benützer simultan, reattach, etc)

[Christian Weisgerber]

On 2022-11-18, Marc SCHAEFER <scha...@alphanet.ch> wrote:

> Das Problem besteht wahrscheinlich auch bei Firefox: das Problem, ist
> das "firefox&" wird einfach mit dem schon gestarteten Chrom oder Firefox
> Programm kommunizieren, ohne DISPLAY beim anderen Prozess ändern zu können.

$ firefox -h
...
--new-instance Open new instance, not a new window in running instance.
...

[Sieghard Schicktanz]

Hallo Ulli,

Du schriebst am Thu, 17 Nov 2022 23:24:07 +0000 (UTC):

> Das X11 Protokoll uebertraegt nur Video, kein Audio.

AFAIK überträgt das X11-Protoko doch "nichtmal" Video, sondern nur
_Grafik_ (-Befehle und deren Daten)?

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Kay Martinen]

Am 18.11.22 um 21:30 schrieb Sieghard Schicktanz:

> Hallo Ulli,
>
> Du schriebst am Thu, 17 Nov 2022 23:24:07 +0000 (UTC):
>
>> Das X11 Protokoll uebertraegt nur Video, kein Audio.
>
> AFAIK überträgt das X11-Protoko doch "nichtmal" Video, sondern nur
> _Grafik_ (-Befehle und deren Daten)?
>

Ja, ich erinnere mich jetzt das auch so gelesen zu haben. Es ist also
kein Videostream sondern es werden... ja weiß nicht... die
Rendering-daten vom Programm nicht an den lokalen sondern einen
Entfernten X-Server gesendet.

Das wirft die Frage auf ob das dann z.b. auch mit einem youtube-video im
Firefox liefe - und was Compiz oder andere Effekte-Manager (weiß grad
nicht wie die genannt werden) da machen, erlaubten oder vereiteln
würden. ???

[Christian Weisgerber]

On 2022-11-18, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> "Alles ist ein PC!"

Passend zum Thema noch eine Anekdote:

In der Unix-AG (studentische Gruppe an der Uni Kaiserslautern)
hatten wir alle Rechner auch als X-Terminal konfiguriert. Man konnte
sich von jedem Rechner grafisch nicht nur lokal, sondern auch auf
jedem der anderen Rechner einloggen.

Einige Nutzer haben dann beklagt, wenn sie sich von der Sun (Solaris)
auf dem PC (Linux) einloggt und das damals noch junge KDE gestartet
haben, dass dann eine häufig benötigte Taste kein Zeichen mehr
geliefert hat. 100% reproduzierbar.

Großes Kopfkratzen.

Irgendjemand hat schließlich herausgefunden, dass eines der
Startup-Skripte von KDE mit xmodmap eine Taste (um)belegt hat und
diese Taste mit ihrem Keycode identifiziert hat - was halt auf einer
Sun und deren X11-Server unter Solaris eine ganz andere Taste war
als die erwartete auf der PC-Tastatur unter XFree86.

[Christian Weisgerber]

On 2022-11-18, Diedrich Ehlerding <diedrich....@t-online.de> wrote:

> - im xterm, also aus der lokalen grafischen Session heraus,
> "ssh -X ${ferne_UserID}@${fernes_System}" oder "ssh -Y ..."
> (den Unterschied habe ich noch nicht genau verstanden).

Bei -X sind die Rechte der Clients mit der X11-SECURITY-Erweiterung
eingeschränkt. Das war ein spät aufgepfropfter Versuch, das quasi
nicht vorhandene Sicherheitskonzept von X11 etwas zu verschärfen.
Anwendungen kommen damit nicht notwendigerweise klar. Wenn man z.B.
mit -X ein xterm(1) startet und dann versucht, ein Stück Text darin
mit der Maus zu selektieren, dann knallt es...

xterm: warning, error event received:
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 427
Current serial number in output stream: 428

... und das xterm stirbt.

Mit -Y haben Clients den traditionell uneingeschränkten Zugriff.
Wenn du dich mit -Y auf einem fernen Rechner einloggst, dann könnte
der dortige Superuser einen Client starten, der zurück auf deinen
lokalen X11-Server zugreift und dort Daten abgreift oder sonstigen
Schabernack treibt.

> oder auf dem lokalen Rechner im xterm "xhost +" (oder besser die
> erlaubtebn Clients näher spezifizieren) und auf dem fernen Rechner
> "export DISPLAY=${lokaler_Rechner}:0.0" (bzw. nach dem Rechnernamen das,
> was lokal in "echo $DISPLAY" steht und dann dort ein Grafikprogramm
> starten.

Dazu muss der lokale X11-Server auch Verbindungen aus dem Netz
annehmen, was der Xorg-Server heute standardmäßig nicht mehr tut,
sondern man muss ihn dazu mit der Option "-listen tcp" starten,
siehe Xserver(1).

"xhost +" erlaubt beliebige Verbindungen von beliebigen Rechnern,
die dann auch beliebigen Zugriff auf laufende Clients haben.
Für eine minimale Authentisierung gibt es stattdessen xauth(1).

[Christian Weisgerber]

On 2022-11-18, Christian Weisgerber <na...@mips.inka.de> wrote:

> Wenn du dich mit -Y auf einem fernen Rechner einloggst, dann könnte
> der dortige Superuser einen Client starten, der zurück auf deinen
> lokalen X11-Server zugreift und dort Daten abgreift oder sonstigen
> Schabernack treibt.

Hat jetzt nichts mit X11 zu tun, aber:

Wenn du dich mit ssh -A (ForwardAgent) auf einem fernen Rechner
einloggst, dann könnte der dortige Superuser zurück auf deinen
ssh-agent zugreifen und eine Verbindung zu einem Drittrechner
aufbauen und die angeforderte Authentisierung mit deinem ssh-agent
und den da hinterlegten Schlüsseln abwickeln, d.h. sich als dich
auf dem Drittrechner einloggen.

Man sollte mit Agent Forwarding also sparsam umgehen. Heimliche
Zugriffe aus der Ferne auf den ssh-agent kann man auch erschweren,
indem man für die Verwendung eines Schlüssels eine explizite
Bestätigung verlangt (ssh-add -c) oder einen FIDO-basierten Schlüssel
(ECDSA-SK, ED25519-SK) verwendet, wo dann der FIDO-Authentikator
eine Berührung als Bestätigung verlangt.

F'up: de.comp.security.misc

[Bastian Blank]

Jan Novak wrote:
> Ich wusste schon, dass es x11 forwarding gibt. Da ich mich nie damit
> beschäftigt habe ... sei's drum.

Es gibt in den letzten Jahren halt immer mehr X-Erweiterungen, welche
nicht Netzwerktransparent sind, also z.B. direkt in die lokale
Graphikkarte schreiben. Diese sind vorallem im Video- und 3D-Bereich
weit verbreitet. Das wird halt alles nicht gehen.

Gerade Browser sind da weit vorne, weil sie halt inzwischen eigentlich
Videoausgabeprogramme sind.

Wenn du mich den Einschränkungen leben kannst, dann tut es.

Bastian

[Sieghard Schicktanz]

Hallo Bastian,

Du schriebst am Sat, 19 Nov 2022 10:07:49 -0000 (UTC):

> Es gibt in den letzten Jahren halt immer mehr X-Erweiterungen, welche
> nicht Netzwerktransparent sind, also z.B. direkt in die lokale

Was meinst Du hier mit "X-_Erweiterungen_"? Eine solche Bezeichnung
impliziert, daß es sich hier um einen Bestandteil des X-_Servers_
handeln müßte, und die laufen ja jedenfalls auf der _darstellenden_
Maschine, sollten also für die "Netzwerktransparen[z]" irrelevant sein.

> Graphikkarte schreiben. Diese sind vorallem im Video- und 3D-Bereich
> weit verbreitet. Das wird halt alles nicht gehen.

Du meinst wohl eher X-_Anwendungen_, d.h. Programme, die auf dem
X-_Client_-System laufen, also der Maschine, die die Daten für den
Server bereitstellt? Etwa wie folgt:

> Gerade Browser sind da weit vorne, weil sie halt inzwischen eigentlich
> Videoausgabeprogramme sind.

Wenn die dann natürlich in den Grafikspeicher der Maschine schreiben,
auf dem sie selber laufen, hat das auf einen netzwerkangebundenen
anderen Computer recht wenig Auswirkung. Und das ist genau das Problem,
das offenbar viele "aktuelle" Software-Ersteller mit dem Prinzip von
X11 haben: es ist eben ein Client-Server-System, ganz anders gedacht
als z.B. die Grafikfunktionen von Windows, das ein reines Einzelplatz-
System für genau eine Maschine ist, die alle nötigen Komponenten
enthält.

[Sieghard Schicktanz]

Hallo Kay,

Du schriebst am Fri, 18 Nov 2022 22:33:02 +0100:

> > AFAIK überträgt das X11-Protoko doch "nichtmal" Video, sondern nur
> > _Grafik_ (-Befehle und deren Daten)?
>
> Ja, ich erinnere mich jetzt das auch so gelesen zu haben. Es ist also
> kein Videostream sondern es werden... ja weiß nicht... die
> Rendering-daten vom Programm nicht an den lokalen sondern einen
> Entfernten X-Server gesendet.

Nein, die Grafikbefehlen und -Daten werden _nur_ an den X-Server
gesendet, der die Darstellung machen soll. Egal, on der am selben
Computer läuft oder auf einem irgendwo anders.

> Das wirft die Frage auf ob das dann z.b. auch mit einem youtube-video
> im Firefox liefe - und was Compiz oder andere Effekte-Manager (weiß
> grad nicht wie die genannt werden) da machen, erlaubten oder
> vereiteln würden. ???

Alles, was mit den - auf effiziente Übertragbarkeit getrimmten -
Grafikbefehlen _nicht_ angebbar ist, muß halt in Form von "Bitmaps"
übergeben werden. Bitmaps sind aber halt nicht die effizienteste Art,
Grafik darzustellen, können aber dafür auch nicht sauber definierbare
Bildinhalte enthalten, wie sie für Video- und Photodarstellung
gebraucht werden. Gerade dafür wurde doch in den letzten Jahr(zehnt)en
eine Menge Entwicklungsaufwand getrieben, dafür, solche Daten möglichst
effektiv komprimieren zu können, um sie möglichst kompakt möglichst
schnell übertragen zu können. D.h. es wäre für eine gute Video- und
Phot-Darstellung unter X11 nötig, diese komprimierten Formate direkt
mit dessen Grafikbefehlen übertragen zu können. Inwieweit das noch in
die Entwicklung eingeflossen ist, weiß ich nicht. Die Entwicklung der
X11-Funktionen ist ja inzwischen nicht mehr gerade enorm stürmisch.
Ich habe auch schon irgendwo gehört oder gelesen, daß X11 garnicht mehr
weiterentwickelt werden sollte, wasich sehr schade fände, gerade wegen
dessen Netzwerkfähigkeit, die der "Ersatz" Wayland prinzipiell nicht
hat. Damit bliebe dann nur noch eine tatsächliche _Video_-Übertragung
der Bildschirmdarstellung, so ähnlich wie bei VNC, wenn auch
hoffentlich wenigstens mit einer guten Komprimierung. Trotzdem braucht
das mal wieder von allem mehr: Bandbreite, Prozessorleistung, damit
Strom, Leitungen und Aufwand allgemein.

[Christian Weisgerber]

On 2022-11-19, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:

>> Es gibt in den letzten Jahren halt immer mehr X-Erweiterungen, welche
>> nicht Netzwerktransparent sind, also z.B. direkt in die lokale
>
> Was meinst Du hier mit "X-_Erweiterungen_"?

X11-Protokoll-Erweiterungen. Die vom Server unterstützten kann man
mit "xdpyinfo -queryExtensions" erfragen.

> Eine solche Bezeichnung
> impliziert, daß es sich hier um einen Bestandteil des X-_Servers_
> handeln müßte, und die laufen ja jedenfalls auf der _darstellenden_
> Maschine, sollten also für die "Netzwerktransparen[z]" irrelevant sein.

Nein, X11-Anwendungen können Erweiterungen gezielt nutzen, z.B.
SHAPE, um nichtrechteckige Fenster darstellen zu lassen.

Es gab schon vor zwanzig Jahren Programme, irgendwelche Spiele, die
zwangsweise MIT-SHM verlangt haben, um Daten über System-V-
Shared-Memory an den Server zu übertragen, was nicht übers Netz
geht.

[Manfred Haertel]

Marc SCHAEFER schrieb:

> Eine Frage noch: unterstützt Wyland ssh -X jetzt?

Vor einigen Jahren hat der Wayland-Chef-Entwickler jedenfalls noch
ziemlich wörtlich die These vertreten, dass solch eine Funktion
"orthogonal" zu seinen Entwicklungs-Zielen wäre.

Was natürlich geht, ist Xwayland laufen zu lassen, was, weil es eben
auch ein echter X Server ist, X11-Anwendungen auch remote darstellen
kann. Und da es immer noch viele X11-Anwendungen gibt und relativ wenig
native Wayland-Anwendungen...

Mittlerweile gibt es aber auch ein paar Krücken zur Remote-Darstellung
in nativem Wayland. Irgendwas mit RDP, was ich aber noch nie ausprobiert
habe.

--
Manfred Härtel, DB3HM mailto:Manfred...@rz-online.de
http://rz-home.de/mhaertel