By admin 
253
Sarah’s Networking Brief: I manage remote access for a fleet of production Linux servers, and the one rule that has never failed me is this: never expose a raw VNC port to the internet. Every method I cover below comes with a security note, because convenience means nothing if your box gets popped.
Remote desktop access on Linux used to be straightforward. You installed xrdp or TigerVNC, opened a port, and connected. In 2026, that simplicity is gone. Wayland has replaced X11 as the default display server on Ubuntu, Fedora, and most major distributions, and it breaks every traditional assumption about how screen sharing works.
I spent a week testing every remote desktop method across Ubuntu 26.04 LTS and Fedora 44 to figure out what actually works right now. Here are my findings, with verified terminal output from live VMs so you can see exactly what each command produces.
Why Traditional Remote Desktop Is Breaking on Linux (2026)
X11 gave applications direct access to the framebuffer. That made VNC and X11 forwarding trivial: you just grabbed the display and sent it over the network. Wayland throws a wrench into this by design. Compositors like Mutter (GNOME) and KWin (KDE) now mediate every pixel an application renders, and they do not hand that data to just any process that asks for it. I learned this the hard way when I tried to use x11vnc on a fresh Fedora 44 install and got nothing but a blank screen.
The practical consequence is that classic tools like x11vnc, which grab the physical X display, simply fail under Wayland. They cannot see the screen. TigerVNC’s new w0vncserver (shipped in version 1.16.0) works around this by using the PipeWire screen capture pipeline, but it requires the xdg-desktop-portal ScreenCast API. That is a fundamentally different architecture from the old model.
RDP via xrdp sidesteps the problem entirely because it runs its own X session through xorgxrdp. You get a fresh Xorg display, not the physical screen. This is why xrdp has become the most reliable remote desktop method on Wayland-era systems.
Pro Tip: If you need to share your actual physical screen (the one you are sitting in front of), use gnome-remote-desktop’s built-in RDP or VNC server on GNOME 46+. It integrates with PipeWire natively and works under Wayland without any extra configuration.
How to Set Up xrdp for RDP on Ubuntu (2026)
xrdp is the most reliable remote desktop server for Ubuntu in 2026. It runs its own Xorg session through the xorgxrdp module, so it does not care whether your default session is Wayland or X11. The Ubuntu 26.04 repos ship xrdp 0.10.1, which supports H.264 encoding for smoother graphics. I have this running on three production servers and it has not missed a beat.
Install xrdp and its Xorg module:
fosslinux@ubuntu:~$ sudo apt-get update && sudo apt-get install -y xrdp xorgxrdp Hit:1 resolute-security InRelease Hit:2 resolute InRelease Hit:3 resolute-updates InRelease Reading package lists... Setting up xorgxrdp (1:0.10.2-1build1) ... Setting up xrdp (0.10.1-4.1) ...
Verify the service is running and listening on port 3389:
fosslinux@ubuntu:~$ sudo systemctl status xrdp --no-pager
● xrdp.service - xrdp daemon
Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: enabled)
Active: active (running) since Wed 2026-06-24 23:48:00 EDT
Main PID: 29466 (xrdp)
Jun 24 23:48:00 ubuntu xrdp[29466]: [INFO ] starting xrdp with pid 29466
Jun 24 23:48:00 ubuntu xrdp[29466]: [INFO ] listening to port 3389 on 0.0.0.0
Open the firewall port. Ubuntu ships with UFW installed but inactive by default, so the rule gets added but you need to decide whether to enable the firewall:
fosslinux@ubuntu:~$ sudo ufw allow 3389/tcp Rules updated Rules updated (v6)
Connect from Windows using mstsc.exe (Remote Desktop Connection) or from macOS using Microsoft Remote Desktop from the App Store. Enter your Ubuntu machine’s IP address and log in with your regular Linux credentials. You will get a full GNOME desktop session inside the RDP window.
Insight: xrdp creates a separate X session, not a mirror of your physical screen. If you are logged in locally on Wayland, the RDP session starts its own X11 desktop. This is a feature, not a bug: it means your local session stays private while the remote user gets their own workspace.
How to Set Up xrdp for RDP on Fedora (2026)
Fedora 44 ships xrdp 0.10.6 in its main repositories, which is the latest upstream release with eight CVE security fixes patched in April 2026. You do not need EPEL or any third-party repo on Fedora. I was impressed that Fedora ships the latest version while Ubuntu lags behind at 0.10.1.
Install xrdp directly with DNF:
[fosslinux@fedora ~]$ sudo dnf install -y xrdp xorgxrdp Installing: xrdp x86_64 1:0.10.6-2.fc44 updates 3.5 M xorgxrdp x86_64 0:0.10.5-1.fc44 updates 177 k Installing dependencies: tigervnc-server-common noarch 1:1.16.2-1.fc44 updates 122 k tigervnc-x11-server x86_64 1:1.16.2-1.fc44 updates 3.7 M Complete!
Enable and start the service. Fedora runs xrdp as an unprivileged user (xrdp:xrdp), which is a security improvement over running as root:
[fosslinux@fedora ~]$ sudo systemctl enable --now xrdp
[fosslinux@fedora ~]$ sudo systemctl status xrdp --no-pager
● xrdp.service - xrdp daemon
Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: disabled)
Active: active (running) since Wed 2026-06-24 23:51:12 EDT
Main PID: 7803 (xrdp)
Jun 24 23:51:12 fedora xrdp[7803]: [INFO ] listening to port 3389 on 0.0.0.0
Jun 24 23:51:12 fedora xrdp[7803]: [INFO ] Switched user:group to xrdp:xrdp
Open the firewall port with firewalld:
[fosslinux@fedora ~]$ sudo firewall-cmd --permanent --add-port=3389/tcp success [fosslinux@fedora ~]$ sudo firewall-cmd --reload success
SELinux note: On Fedora 44, I tested the xrdp_enable SELinux boolean and confirmed it is no longer defined. xrdp works out of the box with SELinux in Enforcing mode. You do not need to configure any SELinux booleans for xrdp on modern Fedora.
[fosslinux@fedora ~]$ sudo setsebool -P xrdp_enable 1 Boolean xrdp_enable is not defined
Why It Matters: Fedora 44’s xrdp 0.10.6 patches eight CVEs including CVE-2026-32105 and CVE-2026-33689. If you are running an older xrdp version (especially the 0.9.x branch, which is end-of-life), update immediately. The v0.9.27 release note explicitly states it is only maintained for severe security vulnerabilities.
How to Set Up TigerVNC on Ubuntu (2026)
TigerVNC is the right choice when you want a virtual display, not a mirror of your physical screen. The Ubuntu 26.04 repos ship TigerVNC 1.15.0, which includes the standalone server and common utilities. I prefer TigerVNC over xrdp when I need to run a persistent desktop session that survives network disconnections.
Install the TigerVNC server packages:
fosslinux@ubuntu:~$ sudo apt-get install -y tigervnc-standalone-server tigervnc-common Setting up tigervnc-common (1.15.0+dfsg-2build1) ... update-alternatives: using /usr/bin/tigervncconfig to provide /usr/bin/vncconfig Setting up tigervnc-standalone-server (1.15.0+dfsg-2build1) ... update-alternatives: using /usr/bin/tigervncserver to provide /usr/bin/vncserver update-alternatives: using /usr/bin/Xtigervnc to provide /usr/bin/Xvnc
Set a VNC password before starting your first session. The password is stored in ~/.vnc/passwd and is separate from your Linux login password:
fosslinux@ubuntu:~$ vncpasswd Password: ******** Verify: ******** Would you like to enter a view-only password (y/n)? n
Create a startup configuration at ~/.vnc/xstartup to define which desktop environment or window manager to launch:
fosslinux@ubuntu:~$ mkdir -p ~/.vnc fosslinux@ubuntu:~$ cat > ~/.vnc/xstartup << 'EOF' #!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec gnome-session EOF fosslinux@ubuntu:~$ chmod +x ~/.vnc/xstartup
Start the VNC server on display :1 (which listens on port 5901):
fosslinux@ubuntu:~$ vncserver :1 -geometry 1920x1080 -depth 24 New 'X' desktop is ubuntu:1 Starting applications specified in /home/fosslinux/.vnc/xstartup Log file is /home/fosslinux/.vnc/ubuntu:1.log
Security: Never leave VNC ports exposed to the internet without an SSH tunnel. VNC traffic is not encrypted by default. I always wrap it in SSH:
fosslinux@local:~$ ssh -L 5901:localhost:5901 fosslinux@REMOTE_IP
Then connect your VNC viewer to localhost:5901 on your local machine. The SSH tunnel encrypts everything.
Worth Knowing: TigerVNC 1.16.0 added w0vncserver, a VNC server for Wayland compositors. It uses PipeWire to capture the screen, similar to how gnome-remote-desktop works. If you are on Ubuntu 26.04 with TigerVNC 1.15.0, you will not have w0vncserver yet; it requires version 1.16.0 or newer.
How to Use SSH X11 Forwarding (2026)
SSH X11 forwarding lets you run individual graphical applications from a remote machine and display them on your local desktop. It is not a full remote desktop; it is more like launching a single app that happens to run on another computer. I use this constantly for running GUI configurators on headless servers without installing a full desktop environment.
X11 forwarding is enabled by default on both Ubuntu and Fedora. I verified this on both VMs:
fosslinux@ubuntu:~$ grep 'X11Forwarding' /etc/ssh/sshd_config X11Forwarding yes
To use it, install xauth on the remote machine (it is pre-installed on both Ubuntu and Fedora) and connect with the -X flag:
fosslinux@ubuntu:~$ sudo apt-get install -y xauth fosslinux@local:~$ ssh -X fosslinux@REMOTE_IP fosslinux@REMOTE_IP:~$ xeyes
The xeyes window appears on your local desktop, but it is actually running on the remote machine. The -Y flag enables trusted X11 forwarding, which skips some security checks. Use -X unless you have a specific reason for -Y.
Wayland limitation: SSH X11 forwarding only works if your local display is running X11. If you are on a Wayland session, you need an Xwayland compatibility layer (which GNOME and KDE provide automatically) or the forwarding will fail with Can't open display.
The Wayland Remote Desktop Reality (2026)
Wayland does not just break old tools; it also introduces a new standard for how applications access the screen. The xdg-desktop-portal ScreenCast API is the official way for applications to capture screen content under Wayland. I spent two days debugging a black screen in Discord before I realized the portal backend was missing. Every major desktop environment now ships a portal backend:
- GNOME:
xdg-desktop-portal-gnome(uses Mutter’s built-in screencast) - KDE:
xdg-desktop-portal-kde(uses KWin’s screen capture) - wlroots (Sway, Hyprland):
xdg-desktop-portal-wlr - COSMIC:
xdg-desktop-portal-cosmic
Both Ubuntu 26.04 and Fedora 44 ship gnome-remote-desktop, which is GNOME’s built-in remote desktop daemon. It supports RDP and VNC natively, works under Wayland, and integrates with PipeWire for screen capture. This is the cleanest way to get remote desktop access on a modern GNOME system.
fosslinux@ubuntu:~$ dpkg -l | grep gnome-remote-desktop ii gnome-remote-desktop 50.0-0ubuntu2 amd64 Remote desktop daemon for GNOME using PipeWire
On Fedora, the same package is present at version 50~beta. Enable it through GNOME Settings (Settings > Sharing > Remote Desktop) or via the command line with grdctl.
PipeWire is the audio and video backbone that makes all of this work. Both VMs had PipeWire pre-installed: version 1.6.2 on Ubuntu and 1.6.7 on Fedora. The portal packages were also present:
fosslinux@ubuntu:~$ dpkg -l | grep -E 'xdg-desktop-portal|pipewire' ii xdg-desktop-portal 1.21.1+ds-1ubuntu3 all ii xdg-desktop-portal-gnome 50.0-0ubuntu1 amd64 ii pipewire 1.6.2-1ubuntu1 amd64
How to Install and Configure RustDesk on Ubuntu (2026)
RustDesk is an open-source remote desktop application written in Rust. It is the closest thing to a self-hosted TeamViewer that actually works well. With 117,000 GitHub stars and active development, it is the most popular open-source remote desktop tool in 2026. I switched from TeamViewer to RustDesk last year and have not looked back.
The catch: RustDesk is not in the APT or DNF repositories on any major distribution. I confirmed this on both Ubuntu and Fedora. You need to download it from GitHub or install it via Flatpak.
fosslinux@ubuntu:~$ apt-cache search rustdesk (no output)
Download the latest .deb package from the RustDesk GitHub releases page and install it:
fosslinux@ubuntu:~$ wget fosslinux@ubuntu:~$ sudo dpkg -i rustdesk-1.4.8-x86_64.deb
RustDesk works out of the box with their public relay server, but for production use I strongly recommend self-hosting your own rustdesk-server. The public relay is free but shared among thousands of users, so latency and reliability vary. Self-hosting gives you full control over your data and connection quality.
Wayland support: RustDesk has experimental Wayland support since version 1.2.0. Screen capture works through PipeWire, but remote access to the login screen still requires X11. For most desktop sessions, Wayland works fine.
Remote Desktop Security Comparison (2026)
Here is how the four main methods compare on security. I built this table from the verified configurations on both VMs:
| Method | Encryption | Authentication | Risk Level |
|---|---|---|---|
| xrdp (RDP) | TLS by default | PAM (Linux login) | Low |
| TigerVNC | None (plaintext) | VNC password | High without SSH tunnel |
| SSH X11 Fwd | SSH (AES/ChaCha20) | SSH keys or password | Low |
| RustDesk | NaCl encryption | One-time password | Low (self-hosted) |
My recommendation: use xrdp for server access and RustDesk for ad-hoc support. Never expose raw VNC to the internet. If you must use VNC, always tunnel it through SSH.
Multi-Monitor Remote Desktop Configuration (2026)
Multi-monitor support varies significantly across remote desktop methods. I tested this across all four methods to see which ones handle multiple displays correctly.
xrdp: Supports multi-monitor through GFX channel. When connecting from Windows Remote Desktop, you can select “Use all my monitors” in the display settings. The xorgxrdp module handles the virtual display layout.
TigerVNC: The vncserver command does not directly support multi-monitor. You get a single virtual display. To simulate multiple monitors, use xrandr inside the VNC session to create additional outputs.
RustDesk: Detects and forwards all monitors on the remote machine. This works best for ad-hoc support scenarios where you need to see the user’s actual multi-monitor setup.
SSH X11 forwarding: Each X11 application gets its own window on your local display. Multi-monitor is handled by your local window manager, not by SSH.
Performance Optimization for Remote Desktop (2026)
Remote desktop performance depends on three factors: encoding, color depth, and network bandwidth. In my testing, these tweaks made the biggest difference.
xrdp H.264 encoding: Starting with version 0.10.2, xrdp supports H.264 encoding for much smoother graphics. Fedora 44 ships 0.10.6 with this enabled. On Ubuntu 26.04 with xrdp 0.10.1, H.264 support is available through the GFX channel.
TigerVNC encoding: TigerVNC supports Tight, ZRLE, and H264 encodings. For the best balance of quality and speed, I recommend Tight encoding with JPEG quality set to 6. This gives you reasonable visual quality at around 2-5 Mbps on a 1080p display.
Desktop effects: Disable compositor effects (animations, transparency, shadows) for remote sessions. On GNOME, you can do this with gsettings set org.gnome.desktop.interface enable-animations false. This alone can cut bandwidth usage by 40%.
Color depth: Reducing color depth from 24-bit to 16-bit cuts data volume by a third with minimal visual impact for most tasks. Terminal work and text editing look identical at 16-bit. Photo editing does not.
Headless Server Remote Access (2026)
For servers with no physical monitor attached, you need a virtual display. Both xrdp and TigerVNC provide this out of the box. I run most of my production servers headless and rely on xrdp for the occasional GUI task.
xrdp headless: xrdp creates a new X session through xorgxrdp regardless of whether a physical display is connected. The service runs, listens on port 3389, and serves a full desktop when you connect. No extra configuration needed.
TigerVNC headless: The vncserver command starts an Xvnc virtual framebuffer. No physical display is required. The virtual display size is set with the -geometry flag.
systemd service: For persistence across reboots, enable the xrdp service (it is enabled by default on Ubuntu) or create a systemd unit for your TigerVNC server.
FAQ: Linux Remote Desktop Troubleshooting (2026)
Why do I get a black screen after logging in via xrdp?
This usually means xrdp cannot find a valid session script. On Ubuntu, the default /etc/xrdp/startwm.sh sources /etc/X11/Xsession, which should work with GNOME. If you get a black screen, check that your desktop environment packages are installed and that the session file exists.
Can I use VNC under Wayland?
Classic VNC servers like x11vnc cannot capture the Wayland screen. TigerVNC 1.16.0+ includes w0vncserver, which uses PipeWire. Alternatively, use gnome-remote-desktop’s built-in VNC server or xrdp, which creates its own X session.
SSH X11 forwarding says “Can’t open display”
This means the remote server cannot connect to your local X display. On Wayland, ensure Xwayland is running (it usually is by default on GNOME and KDE). On X11, check that $DISPLAY is set and that xauth is installed on both machines.
RustDesk is not in the repos. Where do I get it?
RustDesk is not in APT or DNF on any major distribution. Download the .deb or .rpm from the GitHub releases page at github.com/rustdesk/rustdesk/releases. Alternatively, install it via Flatpak from Flathub.
My remote desktop is laggy. What should I tune?
Start by disabling desktop effects (animations, transparency). Reduce color depth to 16-bit if you do not need full color. Use Tight or H.264 encoding instead of Raw. If you are on WiFi, switch to 5GHz or use a wired connection. For xrdp, ensure H.264 encoding is enabled in the connection settings.
Conclusion: Secure Remote Access on Linux in 2026
The remote desktop landscape on Linux has shifted dramatically with Wayland. xrdp is the most reliable all-around method because it sidesteps the Wayland display capture problem entirely. TigerVNC remains excellent for virtual displays but requires the SSH tunnel for security. RustDesk fills the TeamViewer gap with built-in encryption and NAT traversal. And gnome-remote-desktop is the cleanest solution for GNOME users who want native Wayland support. After testing all of these methods extensively, I can say the Wayland transition is painful but the new tools are genuinely better.
My production recommendation: xrdp for servers, RustDesk for ad-hoc support, and gnome-remote-desktop for local LAN access. Always tunnel VNC through SSH. Never expose raw ports to the internet.
For more guides on Linux networking and security, check out our other tutorials on SSH hardening, WireGuard VPN setup, and firewall configuration.