I enabled the desktop’s built-in remote desktop service on a freshly-rebooted Linux laptop and set credentials from an SSH session:

grdctl rdp enable
grdctl rdp set-credentials exampleuser 'example-password'
grdctl status

Status reported RDP enabled. Clients connected, negotiated, and dropped a second later. No useful error at either end.

The credentials are not stored in a configuration file. They go into the login keyring, which is encrypted with the account’s login password and unlocked by the desktop session at interactive login, something that, on a machine which has just rebooted with nobody sitting at it, has never happened.

So set-credentials writes into a locked store. The command returns success. The service then cannot read back what it needs during authentication, and closes the connection.

There is no way around this from SSH. One interactive login at the physical console, once after each reboot, unlocks the keyring and makes stored credentials readable. After that, remote desktop behaves.

Two consequences worth planning for:

Per-user remote desktop is not a recovery path for a headless machine. It depends on the session you would be using it to reach. If a machine must be reachable after an unattended reboot, that is a system-level service or an out-of-band console, not a desktop feature.

“Command succeeded” is not “credential stored”. Verify by reading it back through the same interface, rather than by checking an exit code.

The diagnostic that pointed at it: every symptom implicated the network or TLS, and none of it was either. A service that authenticates fine while you are logged in and fails after a reboot is describing a dependency on your session.