Forwarding an entire desktop over SSH without third party tools

Question

Something that's always bugged me and I've been unable to find good information on:

How can you or why can't you forward an entire desktop over SSH (ssh -X)?

I'm very familiar with forwarding individual windows using ssh -X. But there are times when I'd like to use my linux laptop as a dumb terminal for another linux machine.

I've always thought that it should be possible to shut down the desktop environment on my laptop and then from the command line ssh into another machine and startup an desktop environment forwarded to my laptop.

Searches online come up with a bunch of third party tools such as VNC and Xephyr, or they come up with the single window ssh commands and config. But that's NOT what I'm looking for. I'm looking to understand a little of the the anatomy (of xwindows?, wayland?, gdm?) to understand how you'd go about doing this, OR why it's not possible.

---

Note:

1. Xephyr isn't what I'm looking for because it tries to run the remote desktop in a window
2. VNC isn't what I'm looking for for a whole bunch of reasons, not least because it's not X11 forwarding but forwarding bitmaps.

Solution 1

How can you?

I've been using the below method from the (now suspended) Xmodulo site to remote into my entire Raspberry Pi desktop from any Ubuntu machine. Works with my original RPi, RPi2 and RPi3. Of course you have to mod sshd_config to allow X11 forwarding on the remote machine (I'd say client/host, but I believe they are different in X11 from other uses and I may confuse myself). Mind the spaces -- they break this procedure frequently when I can't type.

You then have the entire desktop and can run the machine as if physically connected. I switch to Ubuntu using CTRL+ALT+F7, then back to RPi with CTRL+ALT+F2. YMMV. A quirk: You must physically release CTRL+ALT before hitting another function key when switching back and forth.

Original link: http://xmodulo.com/2013/12/remote-control-raspberry-pi.html

Original work attributed to: Kristophorus Hadiono. The referenced pictures are, sadly, lost.

============== 8< ==============

Method #3: X11 Forwarding for Desktop over SSH

With X11+SSH forwarding, you can actually run the entire desktop of Raspberry Pi remotely, not just standalone GUI applications.

Here I will show how to run the remote RPi desktop in the second virtual terminal (i.e., virtual terminal 8) via X11 forwarding. Your Linux desktop is running by default on the first virtual terminal, which is virtual terminal #7. Follow instructions below to get your RPi desktop to show up in your second virtual terminal.

Open your konsole or terminal, and change to root user. $ sudo su

Type the command below, which will activate xinit in virtual terminal 8. Note that you will be automatically switched to virtual terminal 8. You can switch back to the original virtual terminal 7 by pressing CTRL+ALT+F7.

# xinit -- :1 &

After switching to virtual terminal 8, execute the following command to launch the RPi desktop remotely. Type pi user password when asked (see picture below).

# DISPLAY=:1 ssh -X [email protected] lxsession

You will bring to your new virtual terminal 8 the remote RPi desktop, as well as a small terminal launched from your active virtual terminal 7 (see picture below).

Remember, do NOT close that terminal. Otherwise, your RPi desktop will close immediately.

You can move between first and second virtual terminals by pressing CTRL+ALT+F7 or CTRL+ALT+F8.

To close your remote RPi desktop over X11+SSH, you can either close a small terminal seen in your active virtual terminal 8 (see picture above), or kill su session running in your virtual terminal 7.

Solution 2

I haven't tested this, but as far as I know, it should be possible to shutdown the local X11 server (usually by stopping the X11 Display Manager, whether it's gdm, sddm, the classic xdm or any other *dm), and then logging in on a virtual console and starting a custom X11 session, like this for GNOME:

xinit ssh -X user@remote-server gnome-session 

Or like this for KDE:

xinit ssh -X user@remote-server startkde

Normally, the X11 Display Manager will start the X11 server, present the login dialog and process the authentication (optionally running some initialization scripts as root before and/or after the authentication), then run a single command or script as the logging-in user that will act as the backbone of the session. The classic default version of that script might be found as /etc/X11/Xsession, but desktop environments like Gnome and KDE may replace that with their own commands. This command/script will stay alive through the lifetime of the session: if it dies for any reason, the X11 Display Manager will assume the session was logged out or crashed, and will reset the X11 server and start over.

When you use startx to start a single X11 session from a virtual console without a X11 Display Manager, it is a wrapper script that uses xinit to start the X11 server and the session command/script.

What you want to do, is to start the X11 server, but use ssh -X in lieu of the local session command, to run the actual X11 session command/script in the remote host.

The xinit command will start the local X11 server, but its only client will be the ssh command. That ssh will establish X11 forwarding, connect to the remote host, log in, and run whatever command is needed to start the appropriate desktop environment session at the remote host. Since the $DISPLAY variable and the ~/.Xauthority file will be set by ssh -X, so any X11 application, including a X11 window manager, should be able to run.

However, as the X11 server will not be accessible locally, various performance-improving X11 protocol extensions will automatically be unavailable, and the network connection + SSH encryption will cause some noticeable latency. Any interaction between the window manager and any other X11 application must go through the X11 server, which means two trips through the network each way. So it will definitely be more sluggish than running a local desktop.

Some desktop widgets may also be confused, as you won't necessarily have all the expected levels of access to the hardware devices and/or the system D-Bus of the host when running remotely.

Solution 3

I can do (I think!) what you want to do with Lubuntu/LXDE - I can log into a remote Lubuntu machine with ssh -Y, and an X server running locally (e.g. Quartz on a Mac, or Xming or vcxsrv on Windows), run lxsession, and get an LXDE taskbar running locally. It seems to pick up and manage other X windows, including ones running locally! Most X servers have an option to run either as individual, floating X windows within your client OS, or with a background that can be run fullscreen. See this screenshot, with lxsession (I think the taskbar itself is called lxpanel, a couple of local xterms, the Mac iTerm session that logged in via ssh and started lxsession, a remote lxterm and remote xeyes.

Other distros will require a different command to run the desktop, e.g. for Ubuntu or Mint with GNOME, I think it's gnome-session, although I couldn't get that to work on my other machines.

Comments

[111---]

Honestly, with the client / server architecture of X, the network lag of sending mouse / keyboard events over the network to the render might be the biggest reason this is not more widespread. If latency crept up, the user experience would be pretty horrible. Just a thought.

[Philip Couling]

I'm not sure that what I'm asking for is sending mouse and keyboard. My belief is that there is a division of responsibility between something (xwindows / wayland?) which renders windows to a monitor and takes mouse and keyboard and something (gdm?) which is responsible for laying out my desktop - menus and all. Based on this belief I'm asking how to run gdm? on one machine connected to xwindows? on another. I really don' know how it's structured so can only ask in higher level terms

[dirkt]

The thing is, you can't move existing X-client-to-server connections to a new server. If you shutdown an X server, all if its client will shut down. So when you start a new X server, you'll have to start all clients again, which means any state will be lost.

[Philip Couling]

@dirkt I am not looking to move an existing session! As stated in the question ssh into another machine and startup an desktop environment forwarded to my laptop the emphasis here is on startup a new session.

[wizzwizz4]

The images aren't lost: web.archive.org/web/20160318000143/http://xmodulo.com/…