Headless remote sessions in GNOME, Part 1

If you need to access a remote system, the usual way is using ssh. 

There are some cases where you need to access a remote system to provide remote assistance to a user in a graphical environment, the user located at the remote system should set up and start a VNC server attached to that desktop and then you could access it with a VNC client.

Sometimes there’s a situation where you need to have a graphical environment in a system which doesn’t have any display. How could that be done? Starting a headless graphical session, combine that session with a VNC server, and then, from a different system with a VNC client access that graphical session. This also works in systems with a display, where you want to use a graphical session remotely without being displayed at the remote display.

All these VNC approaches can be done with tigervnc and Xorg. 

So, everything is great to graphically access remotely! Well, not completely. Xorg and VNC are not perfect. Xorg has some security vulnerabilities based on its design. VNC also isn’t well suited for security contexts, its default security method is insecure and has some performance issues.

Remote Desktop in Wayland

In these times, Xorg is moving to the obsolete world and Wayland is replacing it. This would make you wonder: What remote desktop solutions Wayland provides? The way Wayland is designed makes each desktop implement the Wayland protocol, that implementation is called a Wayland compositor. Each desktop has its own compositor, KDE has KWin, GNOME has Mutter, and so on. 

Because each desktop has its own compositor, each desktop has its own remote desktop solution. Maybe the future will change that, but this is the current situation. The official desktop SUSE supports is GNOME, so we will focus on it.

GNOME Remote Desktop

The remote desktop program GNOME uses is called gnome-remote-desktop. What can provide this program? It is a session service that gets the framebuffer of the graphical session using the dbus interfaces exposed by mutter “org.gnome.Mutter.RemoteDesktop” and “org.gnome.Mutter.ScreenCast”; and pipewire. It’s worth mentioning that those interfaces exist as portals: RemoteDesktop and ScreenCast, maybe if other desktops provide those portals a universal remote desktop solution could work.

Gnome-remote-desktop started providing remote desktop access with the VNC protocol (libvncserver). But after a while, support for the RDP protocol (FreeRDP) was added, which is now the default one.

The original intention of the gnome-remote-desktop was to provide a solution that covers the remote assistance case where a user in the graphical remote system needs help. However, no desktop was providing a solution to cover the headless graphical remote session on Wayland.

Headless Graphical Remote Session 

SUSE has made key contributions for pushing forward the development of the first solution which provides a headless graphical remote session with Wayland. This was done in the GNOME project. The majority of the changes were made at the gnome-remote-desktop, and some at GDM, gnome-session, and FreeRDP. Let’s dig into the details.

The first POC

The first step was to start a headless session and access it with gnome-remote-desktop. One positive thing was that mutter could already be started headlessly using the –headless option. The gnome-remote-desktop was required to see and manage that headless session, however, you need to authenticate (username/password) when you connect with RDP. The first issue was that gnome-remote-desktop relied on gnome-keyring to authenticate the RDP client. Gnome-keyring is only unlocked when the session is physical or you start a session authenticating through a display manager. With the headless situation, you have a remote session starting headless mutter and don’t use a display manager so the gnome-keyring is locked. A solution was added to make gnome-remote-desktop not rely on gnome-keyring when it’s in a headless situation and instead rely on TPM.2 to store the password used to authenticate. A fallback option using a GKeyFile was added too thanks to a SUSE contributor.

Now one could start a headless mutter/gnome-shell and start gnome-remote-desktop, both sharing the same dbus session, and then the session could be used by connecting remotely with an RDP client.

That setup worked as a proof of concept but required some knowledge and work to set it up. The next step was to have a plan to make GNOME support it properly. More details on how it was done in Part 2 and Part 3.