Why do I need XDMCP to start a remote X session over SSH?

Question

I'm trying to set up a remote desktop connection to access my desktop PC from my laptop (both running Trisquel) over wifi. I've tried VNC and it was terribly slow, so I'm looking at alternative options. What I would ideally like to do is to start a remote X session over SSH, which would run on a separate tty on my laptop (i.e. tty8), using X forwarding. It seems like it should be possible, but I'm trying to get my head around how it works.

The X forwarding over the SSH tunnel seems to work fine for individual X applications, using ssh -X. I can also start a new local X session on tty8 by using the following command (with xinit installed):

startx lxsession -- :1 tty8

So, putting two and two together, I should be able to start a remote session over the SSH connection by typing the following command after logging in to the remote machine with SSH, right?:

startx gnome-session -- :1 tty8

But no, it doesn't work! I get the following error:

X: user not authorized to run the X server, aborting.

From what I've read, it seems that I need to use either XDMCP and/or X nesting to accomplish this.

So, my question is: why is it necessary to use these extra packages to do this? I thought that X is supposed to have network transparency, in which case, why would it know/care whether the tty I'm trying to use is on a local or a remote machine? What does XDMCP/X nesting bring in to the picture, that X doesn't include by default?

I'm just trying to get my head around this and understand it a bit better.

Solution 1

startx gnome-session -- :1 tty8

If you run this command over a ssh -X session, you are not going to achieve a remote gnome-session for yourself. Instead, you're effectively trying to remote-start a GNOME session on the tty8 virtual console of the remote host, for whoever happens to sit at that computer.

Instead, you would want to first set up SSH keys so that you can run commands on your remote host on your own account without prompts for a password or SSH key passphrase. Then you would run something like this on your local system:

startx ssh -X <remote host> gnome-session -- :1 tty8

You might need to add & to the end to make the command run in the background.

Basically, you'll want:

1) a X server on your tty8, running as its session process...

2) ... the X-forwarding SSH connection to the remote host, where...

3) ...the gnome-session is started and will pass its displays back over the SSH connection back to the "empty" X server on your local tty8.

Note that if GNOME uses advanced 3d acceleration features of the GPU to render its desktop, it will be using direct rendering (= direct memory access between the GNOME window manager and the X server) when running locally. When running a remote session like this, direct rendering won't be possible (as the GPU is not in the same computer as the window manager process!), which may slow things down. In that case, you might have to choose a simpler window manager.

XDMCP is a protocol for controlling X11 terminals: stripped-down computer appliances whose only job is to act as a X11 display+mouse+keyboard for some other computer. The XDMCP protocol was developed way before SSH and is completely insecure. It does not apply to your case, unless you specifically configure the display manager (the gdm, kdm, xdm or any other *dm) to be XDMCP-aware, as XDMCP is disabled by default on modern systems because it isn't secure. If you did that, then you could tell startx to make your local X server pretend it's a X11 terminal, and have it make a direct, unencrypted, non-SSH-forwarded connection to the remote host. (Just say "no".)

X nesting, on the other hand, would allow you to e.g. have a single big window in your regular local X11 session on :0.0 (or tty7), which would then contain the remote desktop session.

Solution 2

I use Xnest for this https://www.x.org/archive/X11R7.5/doc/man/man1/Xnest.1.html

After it is installed (it is in apt for Debian/ubuntu/mint/etc) open a terminal and do

user@localhost:~$ Xnest :1 &
user@localhost:~$ export DISPLAY=:1
user@localhost:~$ ssh -Y user@remotehost
(login, etc)
user@remotehost:~$ mate-session

Alternatively, you can open a VT (ctrl+alt+F1 etc) and start a new X server just by using X :1 and then doing the same export DISPLAY=:1 and sshing in. Personally I prefer Xnest.

Comments

[Time4Tea]

Thanks very much for the detailed answer - this is helpful. So, by inserting the ssh -X into the startx command, I'm essentially telling startx that I want to use the window manager on the remote machine, over the ssh connection? I'm a bit confused by the 'ssh keys' part that you mention. Could you tell me where I can find out more about what that does and how to set it up?

[Time4Tea]

Thanks for your answer. I tried X :1 and that didn't work - gave me an error saying that it 'couldn't open /dev/tty0 (Permission denied)'. So, instead, I tried startx -- :1 and that didn't seem to give the error, but the server didn't stay open - it seemed to just close immediately after I started it. Do you have any idea why that might be?

[ivanivan]

When you call startx it has to have some sort of session to start... first 4 search results here should get you going - google.com/search?q=start+X+and+reference+custom+xsession+fi‌​le

[Time4Tea]

Ok, thanks, I'll take a look at those. Clearly I'm not very experienced in the inner workings of X (but interested to learn) :-)

[telcoM]

For your first question, yes. For the second, google for "ssh key authentication" and you'll find a lot of advice on that.

[Luciano]

This wasn't working for me, with startx complaining about missing /usr/bin/xterm. It turns out that my version of startx completely ignored the command line client argument (it's just a script - you can inspect it). I had to create ~/.xinitrc with the ssh command in it, then it worked.

[telcoM]

@Luciano Yes, startx is a script and different distributions may modify it to suit their particular configuration. The procedure discussed here is a rather special use case which is most likely not expected at all by the distribution maintainers, so it's no wonder there might be a wrinkle or two.