[geloest] SSH, X11Forwarding, "Can't open display"

[Cae]

Hallo zusammen,

auf einer Wheezy-Box möchte ich letztendlich Programme mit grafischen Oberflächen unter einem anderen Benutzer starten, ohne umloggen zu müssen. Die Idee ist, Xephyr (xserver-xephyr) über ssh userb@localhost zu starten, aber so weit komme ich gar nicht.

Relevant sind dafür nach meinen Nachforschungen die beiden schon per default gesetzten Variablen

Code: Alles auswählen

# /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10

und die von mir hinzugefügten

Code: Alles auswählen

# /etc/ssh/ssh_config
Host *
[…]
    ForwardX11 yes
    ForwardX11Trusted yes

in der globen Client-Konfiguration. Danach hatte ich den sshd reloaden lassen und ssh -X userb@localhost probiert:

Code: Alles auswählen

% ssh -tX userb@localhost sh
X11 forwarding request failed on channel 0
$ 

(Das Verhalten ist auch ohne die Änderungen gleich.) Der spannende Teil von -vv sieht so aus:

Code: Alles auswählen

debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: sh
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 100 id 0
X11 forwarding request failed on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0

Angenommen, X-Forwarding würde nun funktionieren, sollte ein in der SSH-Shell eingetipptes xclock ein lokales X-Fenster starten. Das passiert aber nicht:

Code: Alles auswählen

$ xclock
Error: Can't open display: 
$ echo -n $DISPLAY | wc -c
0

Macht ja auch irgendwo Sinn, wenn $DISPLAY nicht gesetzt ist. Falls es auf :0.0 steht, oder :0 oder irgendein (von mir probierter) anderer Wert, lautet die Meldung

Code: Alles auswählen

$ xclock
No protocol specified
Error: Can't open display: :0.0

Was ist der korrekte Wert für $DISPLAY, bzw. liegt es überhaupt daran? Die Dokumentationen (tldp beispielsweise) erklären lang und breit, wie man X zum Laufen bekommt, oder SSH, aber X11-Forwarding scheint grundsätzlich und immer zu gehen… Andere User haben entweder kein xauth installiert (habe ich), kein X11Forwarding in der sshd_config (habe ich), wollen irgendwelche Windows-X-Server zum Laufen bekommen (tja).

Gruß Cae

P.S.: Wer mir verrät, dass ein sudo -u userb Xephyr oder etwas in der Richtung auch geht, gerne. Löst mein Problem, aber die SSH-Unstimmigkeiten nicht.

[shoening]

Hi Cä,

hast Du das schonmal ohne die Client-Konfiguration versucht?

Bei mir liefert dann

Code: Alles auswählen

echo $DISPLAY
localhost:10.0

Ciao
Stefan

[Saxman]

P.S.: Wer mir verrät, dass ein sudo -u userb Xephyr oder etwas in der Richtung auch geht, gerne. Löst mein Problem, aber die SSH-Unstimmigkeiten nicht.

Den Umweg über X-Forwarding spare ich mir auf localhost. Unter Gnome habe ich das immer mit gksu gemacht, unter KDE mache ich das über kdesu. Hier laufen mehrere Programme unter anderen Benutzern ohne Probleme. Wenn es also nur darum geht...

[hupfdule]

Debian (und die meisten anderen Distributionen) starten den XServer standardmäßig mit der Option "-nolisten tcp". Damit ist das Forwarding auf diesen Server grundsätzlich unterbunden.
Umstellen kannst du das in der Datei "/etc/X11/xinit/xserverrc" (benötigt allerdings einen Restart des XServers).

[debdog]

auf einer Wheezy-Box möchte ich letztendlich Programme mit grafischen Oberflächen unter einem anderen Benutzer starten, ohne umloggen zu müssen. Die Idee ist, Xephyr (xserver-xephyr) über ssh userb@localhost zu starten, aber so weit komme ich gar nicht.

Ich könnte die Problemstellung nicht richtig verstanden haben, aber wenn Du wirklich nur ein Programm starten möchtest, dann brauchst Du dafür keinen verschachtelten X-Server. Einfach einloggen und das Programm starten.
Hier, allerdings noch unter Squeeze, funzt das ohne Probleme mit der selben ssh-Konfig, die Du angegeben hast und ohne "/etc/X11/xinit/xserverrc" abzuändern.

Code: Alles auswählen

user1@PC:~$ ssh -l user2 localhost
user2@localhost's password: 
[...]
user2@PC:~$ scite &
[1] 2129

[r900]

P.S.: Wer mir verrät, dass ein sudo -u userb Xephyr oder etwas in der Richtung auch geht, gerne. Löst mein Problem, aber die SSH-Unstimmigkeiten nicht.

Den Umweg über X-Forwarding spare ich mir auf localhost. Unter Gnome habe ich das immer mit gksu gemacht, unter KDE mache ich das über kdesu. Hier laufen mehrere Programme unter anderen Benutzern ohne Probleme. Wenn es also nur darum geht...

Genau für diesen Zweck gibt es doch sux.

Code: Alles auswählen

user@host~$ sux testuser xclock

Das ist ein wrapper für su. Wenn du dir das Script anschaust siehst du auch welche Rechte auf testuser transferiert werden müssen.

Du kannst das aber auch umgehen indem du Xephyr mit dem Benutzer startest unter dem die aktuelle X-Sitzung läuft.

Code: Alles auswählen

user@host::~$ Xephyr :2 &
user@host:~$ su testuser
testuser@host:~$ DISPLAY=:2 xclock

Ich denke so ist das eigentlich gedacht oder hab ich da was falsch verstanden? Weshalb sollte testuser Xephyr starten, reicht doch wenn er die Programm startet die darin laufen.

[Saxman]

P.S.: Wer mir verrät, dass ein sudo -u userb Xephyr oder etwas in der Richtung auch geht, gerne. Löst mein Problem, aber die SSH-Unstimmigkeiten nicht.

Den Umweg über X-Forwarding spare ich mir auf localhost. Unter Gnome habe ich das immer mit gksu gemacht, unter KDE mache ich das über kdesu. Hier laufen mehrere Programme unter anderen Benutzern ohne Probleme. Wenn es also nur darum geht...

Genau für diesen Zweck gibt es doch sux.

Code: Alles auswählen

user@host~$ sux testuser xclock

Das ist ein wrapper für su. Wenn du dir das Script anschaust siehst du auch welche Rechte auf testuser transferiert werden müssen.

Viele Wege führen nach Rom...

[Cae]

hast Du das schonmal ohne die Client-Konfiguration versucht?

Ja, auch dann bleibt $DISPLAY leer. Irgendwas stimmt da nicht.

Unter Gnome habe ich das immer mit gksu gemacht, unter KDE mache ich das über kdesu. Hier laufen mehrere Programme unter anderen Benutzern ohne Probleme. Wenn es also nur darum geht...

Die Idee war u.A. auch mal, passwortlose SSH-Keys zu verwenden, um übertrieben häufiges Einloggen zu vermeiden. Ich meine aber einst von einem gksudo (?) gehört zu haben, das die sudoers verwendet und den X-Kram drum herum strickt. Das klingt nach dem passenden Weg.

Nur leider macht gksudo irgendwo die Grätsche, ich bekomme

Code: Alles auswählen

% gksudo -u userb xterm

(gksudo:11142): GLib-CRITICAL **: g_str_has_prefix: assertion `str != NULL' failed

Das passiert auch bei beliebigen anderen Programmen als Argument. (Und dieser verschwenderische Kerl, der die überflüssige Newline da reingepackt hat, gehört auf Typenraddrucker umgeschult.)

mit der Option "-nolisten tcp". Damit ist das Forwarding auf diesen Server grundsätzlich unterbunden.

Aha, über diese Option war ich früher mal gestolpert (und da hatte das Forwarding auch geklappt, kann aber unabhängig sein). Übrigens bleibt bei mir immernoch -nolisten tcp in top stehen, des Rätsel Lösung: xinit/xserverrc scheint nur bei manuellem xinit zu gelten, mein WDM hat das seperat in der /etc/X11/wdm/Xservers stehen. Da steht auch

Code: Alles auswählen

# - SECURITY NOTE: Always pass the "-nolisten tcp" option to the X
#   server, as shown in the examples below, unless you know you
#   need the X server listening on a TCP port.  Omitting this
#   option can expose your X server to attacks from remote hosts.
#   Note also that SSH's X11 port-forwarding option works even with
#   X servers that do not listen on a TCP port, so you do not need
#   to remove the "-nolisten tcp" option for SSH's benefit.

… was sich mit meiner Beobachtung deckt, denn mit nicht-deaktiviertem TC-Protokoll geht's auch nicht.

nur ein Programm starten möchtest, dann brauchst Du dafür keinen verschachtelten X-Server.

Das weiß ich ehrlich gesagt selbst noch nicht, aber wenn denn ein einzelnes laufen würde, würde Xephyr ja auch starten. Eigentlich macht das keinen Sinn, ich will ja keine Desktops testen, sondern Programme.

Weshalb sollte testuser Xephyr starten, reicht doch wenn er die Programm startet die darin laufen.

Aha! Natürlich, das erklärt auch die Verwirrung, nachdem ich mit sux Xephyr gestartet hatte und anschließend (aus einem usera-Terminal) probehalber awesome im zweiten X gestartet hatte. Da hat das X userb gehört, aber die Session eben noch usera.

Mein Versuch, sux auf sudo umzustricken, geht übrigens in die Hose:

Code: Alles auswählen

--- /usr/bin/sux        2010-10-10 21:19:05.000000000 +0200
+++ tmp/sux     2012-10-24 23:00:20.479038912 +0200
@@ -340 +340 @@
-exec su $sux_su_opts -c "$sux_xauth_cmd \
+exec sudo -u $sux_su_opts sh -c "$sux_xauth_cmd \

Es wird wohl der Cookie nicht kopiert.

Gruß Cae

[uname]

Etwas offtopic:

Ich meine aber einst von einem gksudo (?) gehört zu haben

Wohl zu oft Ubuntu genutzt Richtiger wäre der Befehl "gksu" aus gksu, welches jedoch auch gksudo enthält. Wenn doch "gksudo" dann aber bitte /etc/sudoers mit "visudo" korrekt konfigurieren.

[habakug]

Hallo!

Ich kann das Problem hier insoweit nachstellen, dass es aus einer root-Shell *nicht* geht:

Code: Alles auswählen

root@work ~# echo $DISPLAY

root@work ~# xhost
xhost:  unable to open display ""
root@work ~# ssh -X user2@localhost
user2@localhost's password: 
Last login: Thu Oct 25 12:17:21 2012 from work
user2@work ~$ echo $DISPLAY

user2@work ~]$ xhost
xhost:  unable to open display ""
user2@work ~$ gedit &
[1] 2216
user2@work ~$ 
** (gedit:2216): WARNING **: Could not open X display
Anzeige kann nicht geöffnet werden:

Aus einer User-Shell funktioniert es jedoch hervorragend:

Code: Alles auswählen

user1@work ~$ xhost
access control enabled, only authorized clients can connect
SI:localuser:user1
user1@work ~$ echo $DISPLAY
:1
user1@work ~$ ssh -X user2@localhost
user2@localhost's password: 
Last login: Thu Oct 25 12:19:40 2012 from work
user2@work ~$ echo $DISPLAY
localhost:10.0
user2@work ~$ xhost
access control disabled, clients can connect from any host
user2@work ~$ gedit &
[1] 2273

Eben auf einer anderen Maschine mußte noch als User

Code: Alles auswählen

user1@work2 ~# xhost +localhost

ausgeführt werden.

Gruß, habakug

[uname]

Eigentlich doch logisch. Beim ersten Beispiel gehört natürlich nicht "root" das Display sondern dem angemeldeten Benutzer. Ein

Code: Alles auswählen

xhost +localhost

als normaler Benutzer hätte auch dort wahrscheinlich geholfen. Bevor man eine SSH-Verbindung mit X aufbaut sollte auch z.B. ein "xterm" für den Ursprungs-Benutzer gehen. Vorher braucht man gar nicht anfangen.

[r900]

Also dann wäre es doch am einfachsten wenn Benutzer A Benutzer B den Zugriff auf die X-Session erlaubt:

Code: Alles auswählen

usera@host:~$ xhost +si:localuser:userb
localuser:userb being added to access control list
usera@host:~$ sudo -u userb xclock

Dann musst du nur sudo so konfigurieren dass usera Befehle als userb ausführen darf, eventuell auch ohne Passwortabfrage.

Das entscheidende bei habakugs erstem Beispiel ist meiner Meinung nach dass die DISPLAY-Variable nicht gesetzt ist.

[hupfdule]

Code: Alles auswählen

# - SECURITY NOTE: Always pass the "-nolisten tcp" option to the X
#   server, as shown in the examples below, unless you know you
#   need the X server listening on a TCP port.  Omitting this
#   option can expose your X server to attacks from remote hosts.
#   Note also that SSH's X11 port-forwarding option works even with
#   X servers that do not listen on a TCP port, so you do not need
#   to remove the "-nolisten tcp" option for SSH's benefit.

… was sich mit meiner Beobachtung deckt, denn mit nicht-deaktiviertem TC-Protokoll geht's auch nicht.

Ja, wenn SSHs -X Option funktioniert, dann läuft das. Wenn das jedoch im SSH-Server abgeschaltet wurde, dann muss auf eben jenem Server die DISPLAY-Variable per Hand gesetzt werden (z.B. 192.168.1.55:0.0). Und dann wird diese Option eben relevant. Aber wie mir gerade auffällt, scheint das bei dir ja gar nicht der Fall zu sein und damit sollte dir die Option wirklich egal sein.

[Cae]

Wohl zu oft Ubuntu genutzt

Verwenden die das auch? Tz, nö, Synaptic hat sich in Squeeze/GNOME2 damit immer uid 0 verschafft… aber das ist auch schon lange her.

Wenn doch "gksudo" dann aber bitte /etc/sudoers mit "visudo" korrekt konfigurieren.

Jepp, hab' ich. Das ist ja das Schöne an sudo, dass es eben kein verkapptes su ist, sondern sich gescheit und eben auch passwortlos für userb konfigurieren lässt.

Code: Alles auswählen

usera@host:~$ xhost +si:localuser:userb
localuser:userb being added to access control list
usera@host:~$ sudo -u userb xclock

Dann musst du nur sudo so konfigurieren dass usera Befehle als userb ausführen darf, eventuell auch ohne Passwortabfrage.

Bingo, das funktioniert auch. sudo -u userb xterm und gksudo funktionieren gleichermaßen mit dieser Einstellung. Ohne userb auf der ACL produziert das xterm im ersteren Fall eine (halbwegs) aussagekräftige Fehlermeldung, gksudo macht aber selbst die Grätsche und gibt Müll aus.

Und noch schöner, wenn man in der SSH-Sitzung bei zuvoriger xhost-Parametrierung DISPLAY auf :0 setzt und xclock startet, läuft es auch. Allerdings halte ich das für einen Spezialfall, da über SSH zwar der Befehl geht, aber dort der lokale localhost-X kontaktiert wird, was eben nicht über SSH zurück geht. Das passiert alles auf derselben Maschine, daher fällt das nicht weiter auf.

Gruß Cae