Ubuntu Remote Desktop Without a Monitor

How to use Ubuntu remote desktop without a monitor

To use Ubuntu remote desktop without a monitor, turn on GNOME Remote Desktop in its Remote Login mode. Remote Login starts its own GNOME session from the login screen, so the machine needs no screen and no user already signed in. You set it up once over SSH with grdctl, then connect from any RDP (remote desktop protocol) client on port 3389.

This guide is for an Ubuntu Desktop machine with no monitor attached, such as a home server or a mini PC. It covers Ubuntu 26.04 LTS first, then what is different on 24.04 LTS. If your machine is a VPS (virtual private server) with a light XFCE desktop, xrdp still fits that case, and remote desktop on a Linux VPS with xrdp and XFCE walks through it. This guide does not repeat it.

Why xrdp does not work with GNOME on Ubuntu 26.04

Many older guides install xrdp. On Ubuntu 26.04 that gives you no GNOME desktop. The cause is in the 26.04 release notes: GNOME Shell can no longer run as an X.org session, and the Ubuntu Desktop session now runs only on the Wayland back end. xrdp works only with Xorg, so it has no GNOME session to start.

The popular xrdp installer script from c-nergy.be says the same thing. Its version 1.6, published in May 2026, does not install the xrdp package when it finds a GNOME desktop with no X11 support. Its author says Ubuntu 26.04 with GNOME is not supported, and points GNOME users to the built-in GNOME Remote Desktop.

Other desktops still have a choice. The release notes say KDE on X11, Xfce, MATE, i3 and many others can still start an X.org session, and X11 apps still run through XWayland. For the rest of the release, read what changed in Ubuntu 26.04.1 and when to upgrade.

Desktop Sharing or Remote Login: which one do you need?

GNOME Remote Desktop is the RDP server that comes with GNOME. Upstream describes three ways to run it: remote assistance, single-user headless, and headless remote login. The Settings app shows two of them under two names.

• Desktop Sharing is remote assistance. It mirrors a session that is already running on the machine. You see the same screen a person at the desk would see.
• Remote Login is headless remote login. Your RDP client first shows the GDM (GNOME display manager) login screen, and you sign in to a new session there. Remote Login works over RDP only, not VNC (virtual network computing).

For a machine with no monitor, Remote Login is the mode you want. Desktop Sharing needs a session that already exists. After a reboot, nobody is signed in, so Desktop Sharing has nothing to mirror.

Desktop Sharing has a second trap. The upstream configuration notes say that in remote assistance mode, locking the screen also closes the remote connection. So when the session on the box locks, your Desktop Sharing link drops with it. Remote Login does not depend on a local session, which is why it suits a box that nobody sits at.

The two modes also listen on different ports. GNOME's help says Remote Login takes port 3389. Desktop Sharing then uses a different port, such as 3390, so you may need to type that port into your client. Version 46 of the server added handling for this exact conflict between the system daemon and the per-user daemon.

Check which version you have

lsb_release -ds
apt-cache policy gnome-remote-desktop

apt-cache policy should show an Installed: line with a version. As of 1 November 2026, Launchpad lists 50.2-0ubuntu0.1 in the updates pocket for 26.04 and 46.3-0ubuntu1.2 for 24.04. If Installed: reads (none), install the package:

sudo apt update
sudo apt install -y gnome-remote-desktop

The major version matters, because grdctl changed between 46 and 50. The steps below point out each difference.

Set up Remote Login over SSH on Ubuntu 26.04

You need SSH access to the box. If it does not run an SSH server yet, attach a screen once and run sudo apt install -y openssh-server. If you have a screen attached anyway, you can also use the Settings route in the next section and skip these commands.

Step 1: confirm the service account

grdctl --system does not change the settings as your own user. The 50.2 source shows that it runs itself again through pkexec --user gnome-remote-desktop, so every file it reads must be readable by that account. Check that the account exists:

id gnome-remote-desktop

You should see a uid= line. no such user means the package is not installed.

Step 2: create a TLS certificate

RDP in GNOME Remote Desktop needs a TLS (transport layer security) key and certificate. Upstream says to create the files for the system service as the gnome-remote-desktop user. This is the OpenSSL command from the upstream docs, run as that user:

sudo -u gnome-remote-desktop sh -c 'mkdir -p ~gnome-remote-desktop/.local/share/gnome-remote-desktop && openssl req -new -newkey rsa:4096 -days 720 -nodes -x509 -subj /C=SE/ST=NONE/L=NONE/O=GNOME/CN=gnome.org -out ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.crt -keyout ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.key'

The certificate is valid for 720 days. Write that date down, because you will need to make a new certificate before it expires. Now point the system daemon at both files:

sudo grdctl --system rdp set-tls-key ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.key
sudo grdctl --system rdp set-tls-cert ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.crt

Step 3: set the RDP credentials

These are a separate RDP user name and password. They are not your Linux account. A remote user types this shared pair first, and then signs in at the GDM login screen with their own Linux account. On 26.04, run set-credentials with no arguments and it reads the user name and password from standard input, so the password does not land in your shell history:

sudo grdctl --system rdp set-credentials

Step 4: enable RDP and start the service

sudo grdctl --system rdp enable
sudo systemctl enable --now gnome-remote-desktop.service
systemctl is-active gdm.service

The upstream docs also enable gdm.service, because Remote Login hands you the GDM login screen. Ubuntu Desktop already uses GDM, so the last command should print active. If it does not, run sudo systemctl enable --now gdm.service.

Step 5: check that it is listening

sudo grdctl --system status --show-credentials
systemctl is-active gnome-remote-desktop.service
sudo ss -tlnp | grep 3389

grdctl --system status --show-credentials should show the RDP section as enabled on port 3389, with your TLS files and user name. Without --show-credentials, status still prints the port and TLS files but shows the user name as (hidden). The exact labels differ between versions. systemctl is-active should print active, and ss should print one LISTEN line on port 3389. No line from ss means nothing is listening, so the client will get a refused connection. Read the log with journalctl -u gnome-remote-desktop.service -n 50 to see why.

Step 6: note the certificate fingerprint

The certificate is self-signed, so your RDP client warns about it on the first connection. Print the fingerprint now and compare it with the one the client shows before you accept it:

sudo openssl x509 -in ~gnome-remote-desktop/.local/share/gnome-remote-desktop/tls.crt -noout -fingerprint -sha256

Some clients show a SHA-1 thumbprint instead. In that case, run the same command with -sha1. A fingerprint that does not match means you are not talking to your box.

The Settings path, if you can attach a screen once

If you can plug a screen in one time, the graphical route sets the same mode. GNOME's current help gives this path: open Settings, then System, then Remote Desktop, then Remote Login. Click Unlock and authenticate, then switch on Remote Login.

The Login Details section on that page shows the user name and password your client will need. Verify Encryption shows the certificate fingerprint to compare. When you are done, unplug the screen. Remote Login keeps working because it does not need a local session.

Desktop Sharing is on the other page under Remote Desktop. Switch on Desktop Sharing to let others view the screen, and Remote Control to let them use it. Only do this if you also keep a session signed in, for the reasons above.

What is different on Ubuntu 24.04

Remote Login exists on 24.04 too. Upstream added headless remote login through GDM in version 46.alpha, and Noble ships 46.3. The 46.2 release also fixed CVE-2024-5148, a flaw in the handover from the login screen to the user session, so make sure apt-cache policy shows the updates version and not the original 46.1.

The Settings layout should match. GNOME Settings 46 added the Remote Login page, renamed the old Remote Desktop page to Desktop Sharing, and grouped Remote Desktop under the new System panel. Noble ships Settings 46.7. Do not confuse Remote Login with Secure Shell in the same System panel: Settings 46 gave the SSH switch that name, and it is a different feature.

The biggest command-line difference is set-credentials. In 46.3 it needs both a user name and a password as arguments. It does not prompt. Read the password into a variable first, so it does not end up in your shell history:

read -rsp 'RDP password: ' GRD_PASS; echo
sudo grdctl --system rdp set-credentials rdpuser "$GRD_PASS"
unset GRD_PASS

Every other command in the 26.04 steps above has the same form in 46.3: set-tls-key, set-tls-cert, enable and status. Three features are missing on 24.04, though. Persistent remote login sessions arrived in version 47, so the 46.x build predates them. Save your work before you disconnect, and test what happens to your session when you reconnect. Version 50 also added remote login to headless GDM autologin sessions and Kerberos authentication. On 24.04 you have neither.

If you need xrdp with GNOME specifically, the c-nergy script only refuses GNOME 49 and later, and 24.04 runs GNOME 46. That is a reason some readers stay on the older release, and going back from Ubuntu 26.04 to 24.04 explains what that move really costs.

Automatic login: test it before you rely on it

Some guides tell you to turn on automatic login, so Desktop Sharing has a session to mirror after a reboot. GNOME's help puts that switch under Settings, System, Users, Unlock, Automatic Login. The same page warns that anyone who starts the computer can then use your account and your data.

There is a second reason for care. In user mode, the source stores the Desktop Sharing RDP credentials through libsecret, in your default keyring collection. With automatic login you never type a password at boot. So reboot the box and test a Desktop Sharing connection before you walk away from it. Remote Login does not need any of this, because it starts from the login screen.

Why port 3389 should never face the internet

Do not forward port 3389 on your home router. A public RDP port gets login attempts from strangers, and the only thing between them and your login screen is one shared password. Reach the box through an encrypted path you already control. Two options work well.

Option 1: an SSH tunnel

If you can already reach the box over SSH, forward a local port to the RDP port:

ssh -N -L 13389:127.0.0.1:3389 you@home-box

-L forwards local port 13389 to port 3389 on the box, and -N tells SSH not to run a remote command, because you only want the forward. Keep that terminal open. Point your RDP client at 127.0.0.1:13389. The local port is 13389 and not 3389, because a Windows machine with its own Remote Desktop server turned on already uses 3389. Only the SSH port needs to be reachable from outside.

Option 2: Tailscale

Tailscale puts both machines on one private network, so neither needs an open port on the router. Install it on the Ubuntu box with the commands from Tailscale's Linux docs:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

Install Tailscale on your client computer too, then point the RDP client at the address tailscale ip -4 printed, on port 3389. If the install script stops with an error, fixing Tailscale install errors on Ubuntu covers the common ones. You do not need Tailscale SSH for this. Tailscale SSH serves port 22 only, on the Tailscale address only, and RDP is a separate port.

If ufw is active on the box, you can allow RDP from the tailnet interface only:

sudo ufw allow in on tailscale0 to any port 3389 proto tcp

Then confirm what is really open with how to list the active firewall rules on Ubuntu. Port 3389 should not appear in a rule that allows it from anywhere.

When the connection fails

The client says the connection was refused. Nothing is listening on the port you used. Run sudo ss -tlnp | grep 3389 on the box. No output means the service is stopped or RDP is not enabled, so repeat Step 4 and read journalctl -u gnome-remote-desktop.service -n 50. Through an SSH tunnel, also check that the ssh -N window is still open.

The client asks for a password twice. That is normal for Remote Login. The first prompt wants the RDP pair you set with set-credentials. The second is the GDM login screen, which wants your Linux account. Typing the Linux password at the first prompt fails, because the two are separate.

You expected your open session but got a login screen. You connected to port 3389, which belongs to Remote Login. Desktop Sharing runs on a different port when Remote Login is on, so check the port shown in its Settings page.

Desktop Sharing drops after a while. The session on the box locked. In remote assistance mode, locking the screen closes the remote connection. Use Remote Login for a box with no monitor.

set-credentials fails on 24.04. Version 46.3 needs both arguments. Use the read -rsp form from the 24.04 section.

FAQ

Can I use xrdp with GNOME on Ubuntu 26.04?

No. The Ubuntu 26.04 release notes say GNOME Shell can no longer run as an X.org session, and xrdp works only with Xorg. The c-nergy.be installer refuses to install xrdp on GNOME 49 and later for this reason. Use GNOME Remote Desktop with Remote Login, or use xrdp with a desktop that still has an X.org session, such as XFCE.

Does Ubuntu remote desktop work with no monitor attached?

Yes, in Remote Login mode. Upstream calls it headless remote login: your RDP client gets the GDM login screen and you sign in to a new session, so no local screen or signed-in user is needed. Desktop Sharing is different. It mirrors a session that is already running, so after a reboot with nobody signed in there is nothing to share.

Which port does GNOME Remote Desktop use on Ubuntu?

Remote Login uses port 3389, the standard RDP port, which is also the default in the gnome-remote-desktop source. When Remote Login is on, Desktop Sharing moves to a different port, such as 3390, and you type that port into your client. sudo ss -tlnp on the box shows what is really listening.

Is it safe to forward port 3389 on my router?

Do not do it. A public RDP port invites login attempts, and one shared password is all that stands in front of your login screen. Forward a local port over SSH with ssh -N -L 13389:127.0.0.1:3389 you@home-box, or put both machines on Tailscale and connect to the box's Tailscale address on port 3389.

Does Remote Login work on Ubuntu 24.04?

Yes. Headless remote login arrived in gnome-remote-desktop 46, and Ubuntu 24.04 ships 46.3. The main difference is that grdctl --system rdp set-credentials on 46.3 needs the user name and password as arguments, while 26.04 can read them from standard input. Persistent remote login sessions only arrived in version 47, so save your work before you disconnect on 24.04.