Remote Desktop in GNOME: A Complete Guide on Linux

If you work with Linux daily, having a remote desktop properly configured in GNOME It makes all the difference: you can manage servers, help other users, or continue working on your computer even when you're not in front of it. In modern environments like GNOME 44 or GNOME 50The options have changed quite a bit compared to older versions, and depending on the distribution (Debian, Oracle Linux, Ubuntu, etc.) the pre-installed tools are different.

To complicate matters further, several technologies coexist: RDP, VNC, proprietary solutions like AnyDesk or RealVNC Connect, and optimized protocols like X2GoEach one has implications for security, performance, and ease of use. In this guide, we'll sort through the chaos and calmly examine how remote desktop works in GNOME and what alternatives you have if you want to use it in Debian or other distributions.

Remote Desktop in GNOME: what the environment includes and why it sometimes doesn't appear

The GNOME desktop environment offers several ways to access graphic sessions remotelyHowever, not all of them are displayed the same way across all distributions. Conceptually, you have two main scenarios supported by GNOME:

On one side is the desktop sharing of a user already logged inThis is typical when you connect to someone's open session on their PC to provide support or manage the same session from another machine. In GNOME, this is usually managed from the panel. Settings > Sharing > Remote Desktop, using the gnome-remote-desktop component.

On the other hand is the remote login with GNOME login screenIn this case, the remote client does not connect to an existing session, but instead sees the login manager (GDM) and can open a new graphical GNOME session as if it were in front of the machine, which is often referred to as "remote login".

When there is physical access to the server and a monitor plugged in, many GNOME desktops expose the desktop sharing option directly in the Settings interface. However, in distributions like Debian trixie/sid with GNOME 44.8This option may not appear even if you install packages like gnome-remote-desktop, gnome-connections or xrdp, either because the distribution provider has changed the presets, or because the graphical integration is disabled or has not yet been adapted to that version.

In headless environments (servers without monitors, cloud machines, instances in Oracle Cloud Infrastructure, Azure, etc.) things change: GNOME does not always display the "Remote Desktop" graphical panel and solutions such as FreeRDP or X2Go are often used, which launch graphical sessions without the need for a physical monitor.

GNOME, RDP, and gnome-remote-desktop as the desktop server

In modern GNOME, the key component for offering Remote desktop via RDP It's gnome-remote-desktop. This daemon can function both as a user service (to share the current session) and as a system service (for headless multi-user access), and is managed with the command-line utility. grdctl.

In general terms, the process for setting up an RDP server with GNOME as the backend involves these steps: Install GNOME and FreeRDP, configure TLS, register RDP credentials, and activate the service.In environments like Oracle Linux, this is done on a system without a graphical environment, and the GNOME desktop is installed from scratch along with the RDP software.

First, a complete GNOME desktop environment with all its dependenciesensuring the system is up to date and restarting if necessary. Then the FreeRDP package is added, which is the free implementation of RDP protocol used to serve and/or test remote connections.

To enable a headless multi-user RDP server, it is necessary generate a key and a TLS certificate self-signed. A specific directory is created to house them, a tool like winpr-makecert is used to generate the .key/.crt pair, and then gnome-remote-desktop is told where those files are located using grdctl commands.

The next step is to define the RDP credentialsThese credentials (username and password) are what the RDP client will use to establish the session that displays the GNOME login screen. It's important to understand that this does not replace local system accounts: to enter a real desktop session, the user must log in with a valid Linux user account and their usual password.

Once the TLS key, certificate, and credentials have been set, it is advisable to run the command to gnome-remote-desktop status with the option to show credentialsTo verify that the key and certificate match (same base name and path) and that the username and password are the ones you intended. This preliminary verification saves a lot of headaches later.

After the TLS and accounts section, it Enables and starts the Remote Desktop RDP service At the system level, systemctl is used to verify that it is active, the GDM service and the remote login service are activated at the system level, and gnome-remote-desktop is configured as the default service to start on every reboot.

Finally, it's good to confirm that The server is indeed listening on port 3389This is typical of RDP, and can be done with a command like: `sudo ss -lnpA inet | grep -e gnome-remote`. If you see port 3389 open and associated with the correct process, the server side is ready.

Headless servers and FreeRDP: access for one or more users

Many modern deployments involve working with headless servers in the cloudIn these cases, GNOME does not display desktop sharing panels, and it is more practical to treat the machine as a generic RDP server with multi-user sessions.

FreeRDP comes in here as a free implementation of Remote Desktop Protocol which can act both as a client and, in certain scenarios, integrate with server services. This combination allows for sessions for one or more simultaneous users, each with their own graphical session, something very useful in practical laboratories or training environments or in a virtual desktop infrastructure where several students access the same host machine.

Setting up the environment usually follows a very similar order to that seen in guides for Oracle Linux: open terminal, connect via SSH to the node (for example ol-node-01), update packages, Install GNOME and FreeRDP and check if a restart is necessary. This transforms a machine without a desktop into a server ready to offer graphical sessions over a network.

In automated deployments with Ansible, it is sometimes necessary to adjust variables such as ansible_python_interpreter For localhost, when installing the Oracle Cloud Infrastructure SDK, this is because the package is located in the system's Python modules path, and Ansible needs to know which interpreter to use. Details such as the instance type (e.g., VM.Standard3.Flex) or the Oracle Linux version, passed via the command line using os_version, are also typically parameterized.

Once the automation is executed, the playbook typically displays the public and private IP addresses of the instances, allowing know which remote address to connect from via RDP or SSHFrom there, it will be enough to open tunnels or expose ports according to the security policy you define.

Client access: Remmina, Connections and other RDP frontends

Once the GNOME server is configured with RDP, you need a compatible remote desktop clientIn Linux, there are several options, but not all of them work equally well with gnome-remote-desktop and FreeRDP.

Among the clients known to perform well are Remmina and GNOME Connections On Linux, it's called xfreerdp, and on macOS, it's called xfreerdp. In labs like Oracle Linux, Remmina is often pre-installed on the Luna Desktop to simplify testing, as it offers a very flexible interface and supports a long list of protocols (RDP, VNC, SSH, etc.).

To connect to a remote RDP server via an SSH tunnel, you can open a terminal and use SSH with the -L option. local port forwardingFor example, mapping remote port 3389 to local port 13389. This way, the RDP connection is made to localhost:13389 but travels encrypted within the SSH tunnel.

Once the tunnel is set up, you open Remmina, create a new connection, and choose RDP – Remote Desktop Protocol as a protocol, and you fill in parameters such as:

• employee: localhost:13389 (or the local port you have chosen).
• RDP Username: the one defined when configuring the RDP credentials on the server.
• Password: the one you set in grdctl.

If you prefer, you can launch the connection directly from a terminal with a command like `remmina -c rdp://user@localhost:13389`. When you connect, you will usually see the GNOME boot manager (GDM)From there you log in with your Linux user credentials (for example, oracle username / oracle password in certain labs).

If you encounter connection problems, the typical solution is to check first SSH connectivity and the tunnelIn cloud environments like Oracle Cloud Infrastructure, you might need additional networking steps: opening ports in the VCN, configuring security lists, or NAT rules to expose the instance. In virtualization environments like Oracle VM VirtualBox, on the other hand, you use port forwarding in the virtual machine's NAT network to redirect RDP connections from the host.

Firewall and RDP port security: direct access vs. SSH tunnel

RDP service is exposed by default in the TCP port 3389On trusted internal networks, you can open this port in the firewall to allow clients to connect directly, but there are important nuances to consider.

Although the modern RDP protocol, and implementations like gnome-remote-desktop with FreeRDP, use TLS to encrypt communicationLeaving port 3389 open to the internet without additional protection is not a good idea. Even on Linux, exposing unfiltered RDP often leads to brute-force attacks, mass scans, and potential vulnerabilities in the RDP stack.

That's why many guides label directly opening the port in the firewall as a Optional and not recommended stepIdeally, RDP should be combined with a secure tunnel, such as SSH, or with a VPN that routes traffic from authorized clients to the network where the server is located.

If you still decide to open port 3389 for direct access on a private network, you will need to create rules in the firewall (for example, using firewalld, nftables, or iptables) that allow this traffic, preferably restricting it by source IP to reduce the attack surface. Even then, it's vital that user accounts use strong passwords and that the system is kept up to date with patches.

Remote desktop performance: GNOME vs. XFCE, Xubuntu, or MATE

The performance of a remote desktop depends on both the network and the graphical environment and the chosen protocolServing a full GNOME environment with effects and animations over RDP is not the same as serving a lightweight XFCE desktop running on X2Go.

In experiences with Ubuntu 20.04/22.04 LTS on Azure Lab Services, it has been observed that GNOME over RDP can introduce noticeable latencyThis is especially true if the connection is poor or if the desktop is overloaded with visual effects. In contrast, lightweight desktops like XFCE, Xubuntu, or MATE tend to run more smoothly with fewer resources.

A highly optimized option for slow networks is X2Go, which uses the NX protocol and benefits from advances in XlibreThis approach compresses and optimizes screen updates very well, allowing for reasonable performance even on links with long latency, especially in Linux-to-Linux scenarios. Many labs recommend the XFCE + X2Go combination precisely because of this performance-to-power-consumption ratio.

In setups with Xubuntu and X2Go, it is usually recommended disable window composition To further improve performance, the compositor adds unnecessary graphical load to a remote desktop. Disabling it and restarting the machine usually results in a much smoother experience.

MATE is another intermediate alternative, with slightly higher resource consumption than XFCE but lower than GNOME, and it also integrates well with X2Go using the same port 22 as SSH, simplifying network setup in labs and educational environments.

Typical remote desktop configurations in Linux labs

In platforms such as Azure Lab Services or educational environments, several are handled frequent combinations of desktop and remote access technologyeach with its advantages:

The combination XFCE + X2Go It is often recommended as the option with the best overall performance. Installation involves adding the XFCE environment, installing the X2Go server, and then students connect using the X2Go client, without needing to change anything in the firewall because X2Go reuses the already open SSH port 22.

Another variant is Xubuntu + X2Gowhich is essentially similar but with the customization and packages that Xubuntu offers. Here, to ensure optimal performance, it is strongly recommended to disable window compositing and restart the template before publishing it to students.

With MATE + X2Go The approach is identical: install MATE, add the X2Go server, and use the X2Go client from the students' workstations. In all these cases, the fact that X2Go relies on SSH is leveraged, avoiding the need to open additional ports.

However, if you want to offer a full GNOME desktop in Azure Lab Services, the recommendation is to use RDP. This requires an additional step during lab creation: enable the RDP connection type to open port 3389, since by default only port 22 is open for SSH and it cannot be changed after creating the lab.

Once RDP is activated, GNOME is installed on the template VM, the RDP server is added, performance adjustments are applied (limiting graphic effects, adjusting RDP compression, etc.) and you can then connect from the student's operating system RDP client.

RDP and VNC clients from Linux: Remmina, Vinagre and others

From the Linux client side, you have several tools to Connect to remote desktops using RDP, VNC, or SSHOne of the most complete is Remmina, which is also widely used in GNOME and Debian environments.

Remmina is a free software project that supports protocols such as RDP, VNC, SSH, SPICE, X2Goamong others. In Debian, the typical installation involves updating the package list, applying updates, and then installing remmina along with the necessary plugins, for example remmina-plugin-rdp and remmina-plugin-secret to have full RDP support and secure credential storage.

Once installed, you can launch Remmina from Activities or from the terminal. It allows you to make quick connections by directly typing the IP address or remote hostname in the top bar, or to create saved profiles with details of resolution, image quality, credentials, etc.

If you need to work regularly with a Windows server from a Debian system with GNOME, the normal thing to do is create an RDP profile In Remmina, point to the DNS name or IP address of the server (for example, a Windows Server 2016), enter the domain username and password, and adjust the full screen or windowed mode.

Remmina also offers a small floating panel when you're in full screenwhich slides up from the top. From there you can switch to windowed mode, log out, or adjust some parameters without letting go of the mouse.

Another classic GNOME application is Vinegar, originally intended as simple remote desktop clientIt supports VNC, RDP, and SSH, and to install it on Debian-based distributions, simply add the vinegar package. It's less powerful than Remmina in terms of options, but for occasional connections or very GNOME-pure environments, it remains a valid tool.

VNC and alternatives: TigerVNC, TightVNC and VNC Viewer

VNC is another family of remote desktop technologies deeply rooted in Linux. It typically involves two components: a VNC server on the remote machine and a client like VNC Viewer on the computer you're connecting from.

TigerVNC It's a high-performance implementation that follows a classic client/server model. To use it on Linux, you can install the package from your distribution's software center or package manager. Once installed, you have utilities to start a VNC server on the machine you want to control and a viewer to connect from another.

The TigerVNC client usually has configuration tabs such as Compression, Security, Input or DisplayThis is where you can adjust the compression level, encryption and authentication methods, accepted input devices, and screen scaling. These options are very useful for adapting the experience to slow connections or screens of different resolutions.

TightVNC It's another free alternative geared towards both remote administration and more routine tasks. On Linux, you can install the server with TightVNC Server and set up separate graphical sessions, while the client is often managed with VNC Viewer, which is available for several platforms.

VNC Viewer is installed from the package corresponding to your distribution and integrates with the VNC servers on your network. The experience is usually very straightforward: you enter the server's IP address or name, the access password, and you can then interact with the remote desktop.

Commercial and multi-platform solutions: RealVNC Connect, AnyDesk and RustDesk

Beyond pure RDP and VNC, there are complete remote desktop solutions that offer intermediation services, advanced encryption and centralized management. For Linux, RealVNC Connect, AnyDesk or RustDesk stand out, all accessible from a modern GNOME.

AnyDesk It is very popular for its simplicity and performance. It uses a proprietary codec, DeskRT, designed specifically for remote desktop connections, allowing it to offer Low latency and good image quality even on connections with limited bandwidth. In low-bandwidth scenarios, some pixelation or blurring may appear, but the experience remains usable.

In terms of security, AnyDesk encrypts sessions with TLS 1.2 and RSA 2048 key exchangeThis keeps communications secure against eavesdropping. It also supports multiple sessions and unattended connections, ideal for accessing computers in remote locations or without on-site staff.

RealVNC ConnectIt, on the other hand, is very business-oriented. It offers end-to-end encryption, multi-factor authentication (MFA)It features SSO integration and can connect to directory infrastructure such as Windows or Azure domain servers. A key advantage is its focus on compliance and centralized management of permissions, devices, and access logs.

In terms of performance, being based on VNC, RealVNC Connect is quite adaptive: adjusts the graphic quality to the connection and allows you to manually define scaling and image quality, prioritizing detail or smoothness as you wish, even before starting the session.

As for the RustDeskIt presents itself as a free alternative that requires virtually no configuration: you can use the public server, host your own server, or connect peer-to-peer. It's developed in Rust and uses the RFB protocol to send screen updates, with features such as file transfer, permission control, unattended mode, and the ability to easily set up your own infrastructure if you want complete control.

When choosing, several factors must be considered: if you drive sensitive data and you need strict complianceRealVNC Connect is usually the most reliable option. For fast, cross-platform remote support with minimal configuration, AnyDesk and Chrome Remote Desktop offer very straightforward experiences. And for Linux-heavy environments that also handle Windows and macOS, RealVNC Connect and RustDesk offer a good balance of compatibility, security, and flexibility.

RDP versus other options: ease of installation and security

Many guides warn that the RDP-based solutions require considerable additional security workUnlike services that come with cloud intermediation or built-in advanced authentication, unfiltered RDP exposed to the internet is often a magnet for attacks.

If you want to use RDP on Linux with acceptable security, it is almost always recommended. Protect it behind a VPNUse access control lists in your firewall and avoid exposing port 3389 freely at all costs. In contrast, tools like RealVNC Connect or AnyDesk don't require you to configure port forwarding or SSH tunnels because they manage traffic through their own services and usually include additional authentication mechanisms by default.

In terms of ease of installation, each solution has its place: while Remmina on Debian or Ubuntu is installed with a couple of commands And it starts working on the fly; setting up xRDP or X2Go involves opening ports, creating firewall rules and, in stricter environments, managing lists of allowed or blocked IPs at the network and user level.

Chrome Remote Desktop is probably one of the simplest to set up for personal use: simply link it to a Google account and follow the wizard. However, precisely because it depends on the Google authentication and management infrastructureSome companies consider it poorly aligned with their security policies.

Use cases: businesses, remote support, and Linux enthusiasts

Not all environments have the same needs, so it's important to distinguish between them. Typical scenarios for using remote desktops in Linux with GNOME and other desktops.

For companies that handle sensitive information, the priority is the security, regulatory compliance and centralized managementIn this context, RealVNC Connect stands out for its end-to-end encryption capabilities, MFA, integration with SSO and RADIUS, and user and device management tools.

For small support teams assisting users in remote locations, tools like AnyDesk or Chrome Remote Desktop They fit together very well, as they allow fast and multi-platform connections with minimal configuration, perfect for handling specific incidents without getting bogged down with VPNs or advanced firewall rules.

In the world of Linux enthusiasts and system administrators, combinations like X2Go, xRDP or VNC with GNOME, XFCE or MATE They allow you to build custom environments with maximum control over ports, encryption, and resources. For those who prefer to work from a Linux desktop but also need to manage Windows and macOS servers, RealVNC Connect and Remmina offer an interesting balance between functionality and usability.

Whatever the case, the key is to be clear about what matters most to you: if what you're looking for is corporate-level security, if it's worth prioritizing ease of use for non-technical users, or if you primarily need performance on limited networks.

Given this overview, it's clear that remote desktop access in GNOME and Linux in general isn't a single tool, but rather a range of options. These range from RDP served by gnome-remote-desktop with FreeRDP and accessible via Remmina, to X2Go and lightweight desktops like XFCE or MATE for improved performance, and even commercial solutions like RealVNC Connect, AnyDesk, or RustDesk that focus on security and convenience. Choosing the right combination to use on your Debian with GNOME or another distribution involves considering network requirements, resources, security, and, above all, how you and your team will work on a daily basis.