You can keep autologin and keep the built-in GNOME Remote Desktop (RDP) working on Ubuntu's Wayland sessions. The breakage has nothing to do with Wayland itself and does not require any third-party remote-control software. The culprit is the GNOME keyring: because nobody types a password at the login screen, the "Login" keyring stays locked, and when gnome-remote-desktop can't read its saved credentials, it silently generates a new random password. Your client then fails authentication after every unattended reboot.
Why autologin locks the keyring
During a normal sign-in, GDM hands your password to PAM, and the gnome-keyring PAM module uses it to unlock the default "Login" keyring in the same breath. Everything stored there — Wi-Fi passwords, browser saves, application tokens — becomes available to your session without further prompts.
Autologin skips the typed password entirely. The desktop starts and your apps run, but the keyring remains sealed. GNOME Remote Desktop stores the username and password that RDP clients use in exactly that keyring. On startup, if it cannot unlock the collection to read them, it assumes no valid credentials exist and mints a fresh random one. That is why the symptom pattern is so recognizable: connections work right after someone logs in locally once, then fail again after the next reboot.
Confirm the diagnosis
Before changing anything, verify that a locked keyring is really the cause. Install the keyring manager if it is not already present:
sudo apt install seahorseOpen Passwords & Keys (seahorse) and expand the Login keyring. Look for an item named something like GNOME Remote Desktop RDP credentials. If it is there and the machine is set to autologin, you have your answer: the credential exists, but the service cannot unlock the keyring to use it after a headless boot.
Fix 1 — a dedicated keyring that unlocks itself (recommended)
Rather than unencrypting all of your secrets, create a small, passwordless keyring used only for the remote desktop credential:
- Open Passwords & Keys and create a new password keyring (the + button). Name it
RemoteDesktop. When prompted to set a password, leave both fields empty and continue past the warning — an empty password means the keyring is stored unencrypted and opens automatically at login. - Right-click the new keyring and choose Set as default.
- Open Settings → Sharing → Remote Desktop (or System → Remote Desktop on newer releases) and re-enter the username and password your clients use, so they are saved fresh.
- Back in Passwords & Keys, confirm the RDP credentials item now lives in the
RemoteDesktopkeyring. If an old copy still sits under Login, delete it to avoid ambiguity. - Set Login as the default keyring again, so future secrets remain encrypted.
From the next reboot onward, gnome-remote-desktop reads its credential from the always-unlocked collection, and remote sharing survives autologin. Only that single secret is plaintext; everything else stays encrypted.
Fix 2 — blank the Login keyring (simple, but blunt)
If you would rather not shuffle default keyrings, set the Login keyring's password to empty: right-click it, choose Change Password, enter your current login password, leave the new password fields blank, and accept the warning. The keyring then unlocks by itself at login and remote sharing works immediately.
The cost is real: every password in that collection — browser logins, tokens, Wi-Fi keys — is now stored in plaintext on disk. On a stationary desktop behind a firewall with full-disk encryption, many people accept that. On a laptop that travels, it is a poor trade. If in doubt, use the dedicated-keyring approach.
Reduce the risk and survive the next outage
- Use full-disk encryption. It protects plaintext keyring data from anyone who gets physical access while the machine is powered off.
- Never expose RDP directly to the internet. Reach your machines over a VPN or an overlay network such as Tailscale instead of port-forwarding 3389.
- Plan around power cuts. Set the BIOS/UEFI to "restore power after AC loss" so machines come back when the utility does, enable Wake-on-LAN as a backup, and let your UPS trigger a clean shutdown before its battery empties. Autologin plus a fixed keyring means the session — and your remote access — return with no hands on site.
- Treat autologin as a physical-access trade. It hands your running session to whoever sits down at the machine. That is reasonable for headless boxes in a locked home office, less so for machines in shared spaces.
Frequently Asked Questions
Why does my RDP password keep changing after reboots?
Because gnome-remote-desktop could not read its credential from the locked keyring, it generated a new random one each time. Fix the keyring problem and the password stops churning.
Is a blank keyring password the same as no password on my user account?
No. It only changes how secrets in that keyring are stored on disk — unencrypted instead of encrypted with your login password. Your user account and its password are untouched.
Does this affect SSH as well?
No. SSH authentication is handled by sshd and PAM and does not depend on the keyring, which is why SSH access keeps working through all of this. Only GNOME Remote Desktop's stored RDP credentials are affected.
Do I need third-party remote-control software for Wayland?
Not for this. The built-in service handles Wayland fine once its credential is readable. Third-party tools such as RustDesk manage credentials outside the keyring, so they sidestep the problem entirely, but they add another listening service you must secure and keep updated.
Where exactly do I change a keyring's password?
In the Passwords & Keys app (seahorse; install it with sudo apt install seahorse if missing). Right-click the keyring, choose Change Password, and leave the new password empty to make it unlock automatically.