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.


  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.
  • 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. – datUser Mar 13 at 0:50
  • 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 – Philip Couling Mar 13 at 10:03

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.

  • 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. – dirkt Mar 13 at 16:35
  • @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. – Philip Couling Mar 13 at 16:55

You can't forward an entire desktop over ssh because that's not how the architecture works.

For X (the graphics system used by Linux), you have an X server running on a particular machine (or, in earlier times, on a piece of dedicated hardware which is not a general purpose computer). X clients can connect to (usually a single) X server, and then the X server will display the window(s) of the clients on the graphics hardware where the X server is running.

Now when you do X forwarding via ssh, everything is set up so that X clients started on the remote machine don't connect to the X server on the remote machine, but instead connect to the X server on your local machine. So any windows of X clients you start within the ssh session are displayed on your local machine. Any X clients that are not part of the ssh session on the remote machine still connect to the remote X server.

If you want to forward "an entire desktop", then first you need some "virtual" X server where X clients can connect to, instead of connecting to a an X server which is bound to real hardware. This virtual X server can then forward connections in various way to other displays.

So yes, you do need something like VNC, Xephyr, Xpra, etc.

If you have specific ideas how to view the content from the remote virtual X server on your laptop (not in a window, and you want to forward the X protocol) then Xpra with cloning probably comes closest (disclaimer: I haven't tried this myself).

Note that there is a big problem forwarding applications which use OpenGL acceleration (today, quite a few) over the X protocol, because you loose hardware acceleration.


Starting up an entire session is an entirely different beast, and not difficult at all, provided no desktop (in particular no window manager) is running on your local X server:

You just need to start up whatever gets normally started up on the remote machine from your ssh connection with the DISPLAY variable pointing to the local X server.

Unfortunately, there are now a number of wildly different ways this is done. For me, because I'm old fashioned, I'd just have to execute /etc/X11/xdm/Xsession, but you will have to do it in whatever Gnome/KDE/systemd decided they want to do it.

  • So what is the architecture (or what features) which prevent it? Eg: an xserver can presumably be started up to do nothing, (unix) socket forwarding can presumably forward all clients from one machine to another and the desktop (background, menus, status bar and other content) is presumably implemented as clients. Have I misunderstood the division of responsibility? – Philip Couling Mar 13 at 13:48
  • You can't start a (hardware bound) display server to "do nothing". If you want an X server that "does nothing", you'll need an X server that's designed to "to nothing", such as the VNC X server, Xephyr, Xpra, Xvfb, etc. There's also no such thing as "unix socket forwarding", you have to implement this in such an X server, like Xephyr or Xpra. You have not misunderstood the division of responsibility, what you failed to take into account is that an existing connection between an X server and an X client is not moveable. If you want to move it, you have to put something "virtual" in between. – dirkt Mar 13 at 16:37
  • It's just like screen or tmux in a terminal: You can't move an existing login (via ssh or otherwise) to some other machine. You need screen etc. in between. – dirkt Mar 13 at 16:41
  • on the contrary, you can forward login by replacing /bin/login with a script to call ssh root@remotehost /bin/login. There is a division of responsibility between the terminal and the login. Screen is a very different tool which creates a virtual terminal that exists irrespective of ssh / login session. – Philip Couling Mar 13 at 16:49
  • Replacing /bin/login with something else is the same as replacing the "normal" X server with Xpra. But see my edit for your actual question (which wasn't clear to me). – dirkt Mar 13 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.