ssh X tunneling in Xephyr window (remote X session)

English Network/Internet
1

The 2 commands below will open an X remote session in a window (one could also do it in a fullscreen desktop page or in another tty, but that’s not the problem):


Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -noreset  :$Screen &
**DISPLAY=$(hostname -f):${Screen}.0** ssh -Y $USER@$server Xres="$res" $Xsession $WM



Xephyr -fp $DEFAULT_FONT_PATH **-ac** -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -reset -terminate :$Screen &
ssh -Y $USER@$server **DISPLAY=$(hostname -f):${Screen}.0** Xres="$res" $Xsession $WM

Where

  • $Screen is the next available (= unlocked) screen on the ssh client (the Xephyr server)
  • $Xsession the script which starts the desktop session on the ssh server. such as /etc/X11/xdm/Xsession for example, but mine looks different.
  • $WM the window manager which should be started and is passed as argument to $Xsession
  • The other variables are not that relevant
  • The ssh client (where these code is executed) is called ‘neelix’. The server is called ‘arpad’.

However:

With code 1:

DISPLAY is on the SSH server (arpad).


echo $DISPLAY
localhost:10.0

but if I set X11UseLocalhost to no in /etc/ssh/sshd_config (the default is yes), I get:


echo $DISPLAY
arpad:11.0

Btw the screen number (started at the value specified in X11DisplayOffset in sshd_config) is not reset and get incremented every time (?).

With code 2:
DISPLAY is on the SSH client (neelix)


echo $DISPLAY
neelix.niglo.net:1.0

With code 1:
ssh prints a warning:

Warning: No xauth data; using fake authentication data for X11 forwarding.

I can get rid on this warning by sending a MIT-MAGIC-COOKIE to the ssh server … however the DISPLAY names don’t match (?)

  • If “1” is the next unlocked screen on neelix, cookie sent/received will be for neelix.niglo.net:1 and DISPLAY is either local:10.0 or arpad:10.0 (depending on sshd settings mentioned above).

With code 2:
ssh prints a warning:

Warning: No xauth data; using fake authentication data for X11 forwarding.

I can NOT get rid on this warning by sending a MIT-MAGIC-COOKIE to the ssh server … however the DISPLAY names match (?)

  • If “1” is the next unlocked screen on neelix, cookie sent/received will be for neelix.niglo.net:1 and DISPLAY is neelix.niglo.net:1.0

code 1:
always works.

code 2:
rarely works the first time and needs several attempts to finally open the DISPLAY. (?)

I don’t know which code to use. Code 1 seems safer, but I prefer code2. I would like to know:

  • why code 2 doesn’t work every time.
  • why does ssh complain when the MIT-MAGIC-COOKIE matches the DISPLAY and not when cookie and DISPLAY don’t match.
  • why code 2 never works if Idon’t disable access control restriction (option -ac in Xephyr - in red in the example code). Code 1 woks with or without -ac.
2

Please disregard this question. I’m not able to reproduce the problem on other servers. It seems to have solved so far.

Also the problem of code 1 is that I can not use -terminate and the display doesn’t get unlocked ( /tmp/.Xn-lock contains a pid of a process which doesn’t exist anymore). If I use -terminate in code1, more precisely this code (the mix of both) :


Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -reset -terminate :$Screen &
DISPLAY=$(hostname -f):${Screen}.0 ssh -Y $USER@$server Xres="$res" $Xsession $WM

I might have to try up to 20 times before beeing able to open a display and get a lot of this error:

connect neelix.niglo.net port 6001: Connection refused
connect neelix.niglo.net port 6001: Connection refused
connect neelix.niglo.net port 6001: Connection refused

However at some point … I will work (???). Whether xdmcp is listening on the server and client doesn’t seem to make a difference… unless I do an Xephyr --query, which is another possibility. In this case, a login manager (xdm,gdm,kdm) has to be running on the ssh server (and xdmcp will be listening to tcp/ip - AFAIK 6000 to 6005 - since I enable it -more exacty I don’t leave it disable).

3

I’ll try to explain why it is a problem. …

...
elif  "$XEPHYR" ]; then
	Screen=$(getScreen)
	sendauth $(hostname -f):${Screen} $server
	which Xephyr &>/dev/null || exec echo "Xephyr is not installed."
	if  "$FULLSCREEN" ] ; then
		Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -fullscreen -name XEPHYR -dpi $DPI -br -noreset :$Screen &
		#Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -fullscreen -name XEPHYR -dpi $DPI -br -reset -terminate :$Screen &
		res=$RES
	else
		Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -noreset  :$Screen &
		#Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -reset -terminate :$Screen &
	fi
	DISPLAY=$(hostname -f):${Screen}.0 ssh -Y $USER@$server Xres="$res" $Xsession $WM
	#ssh -Y $USER@$server DISPLAY=$(hostname -f):${Screen}.0 Xres="$res" $Xsession $WM
	pid=$(cat /tmp/.X${Screen}-lock 2>/dev/null)
	 "$pid" ] && kill -SIGTERM $pid
	exit
elif ...

If I use the code in blue, it will connect immediately but won’t terminate cleanly. After logging out from the remote session, I will have to kill the Xephyr window and the kill command (in green) won’t work and print an error because the process doesn’t exist anymore (since I closed the Xephyr window). Further the Xn-lock file won’t get deleted.

If I use the code in red, it will terminate cleanly. Logging out will close the windows and unlock the X display … but I will have to repeat the command several times before beeing able to connect ( = open a display).

That’s the problem I’m facing here.

4

I solved that one by using

Xephyr -fp $DEFAULT_FONT_PATH  -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br** -noreset -once** :$Screen &

instead of

Xephyr -fp $DEFAULT_FONT_PATH  -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br **-reset -terminate** :$Screen &

Il seems that I can use -noreset -once in both cases. The code now looks like this:

...
elif  "$XEPHYR" ]; then
	Screen=$(getScreen)
	sendauth $(hostname -f):${Screen} $server
	which Xephyr &>/dev/null || exec echo "Xephyr is not installed."
	if  "$FULLSCREEN" ] ; then
		Xephyr -fp $DEFAULT_FONT_PATH -ac -mouse ephyr -keybd ephyr -fullscreen -name XEPHYR -dpi $DPI -br -noreset -once :$Screen &
		res=$RES
	else
		Xephyr -fp $DEFAULT_FONT_PATH  -ac -mouse ephyr -keybd ephyr -screen $res -dpi $DPI -br -noreset -once :$Screen &
	fi
	#DISPLAY=$(hostname -f):${Screen}.0 ssh -Y $USER@$server Xres="$res" $Xsession $WM
	ssh -C -Y $USER@$server DISPLAY=$(hostname -f):${Screen}.0 Xres="$res" $Xsession $WM
	pid=$(cat /tmp/.X${Screen}-lock 2>/dev/null)
	 "$pid" ] && kill -SIGTERM $pid
	exit
elif ...

The command in red connects immediately, exits cleanly and sets DISPLAY to the ssh client (looks more like X remote login). That’s what I wanted.

The command in blue connects immediately, doest NOT exit cleanly (have to close the frozen Xephyr window) and sets DISPLAY to the ssh server (or localhost). That looks more like ssh tunneling. I still would like to know out of curiosity why it doesn’t exit cleanly when I log out. I tried differents things to kill this process within the script, like using bash coproc and waiting for the named pid (NAME_PID) to exit, or checking the parent pid of the Xephyr process in order to find out the pid of the ssh process. But nothing worked. I must be missing a step (I can kill the processes, but not before I close the frozen window. So it’s useless.)

Anyway … sorry for talking to myself and… thanks PTA, you saved my day again. lol!

5

Although I don’t understand the issue at all thanks for sharing :slight_smile: Maybe one day I will see the light and understand the solution as well.