The first time a remote client tries to connect to the RDP server after the system reboots, a local user on the machine needs to approve it. This happens even if the "Allow restoring on future sessions" checkbox is checked (See Bug 488369). This presents a problem for headless remote setups in particular: rebooting the machine for any reason will prevent graphical re-connection. The security offered by the portal is also dubious; RDP connection requests are already protected with the requirement that the client know the username and password of a local user. We should consider methods to bypass the portal's confirmation request for this particular use case.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/36
We have no control over the portal dialog, short of switching to a completely different API. The only thing we can do is to ensure we request permission early and hope the user checks "remember" (and there are no bugs with that setting). Note that we can't even control from within the server if that checkbox is ticked by default. The linked MR implements the above, which hopefully resolves most of this along with the fix to persistence of the "remember" option.
We do have control over it ("we" meaning KDE). We could delete it completely and auto-accept incoming requests, for example.
In progress with https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/297.
Git commit 8cea6fb883bb387c4d1adadad3bfe79b387c1abc by Arjen Hiemstra. Committed on 12/06/2024 at 11:06. Pushed by ahiemstra into branch 'master'. server: Create a single temporary portal session on server startup We want to ask the user for permission when it's convenient, not when there's nobody at the machine to confirm the permissions. So create a portal session at startup to request the permisisons. Unfortunately we cannot reuse this portal session since it leads to reconnection issues with the PipeWire stream. While that is probably solvable it also causes additional problems, most notably that the "Remote Desktop" SNI will be constantly active. So instead, discard the session after it was successfully started and create a new session when a new connection is incoming. This assumes the user checked "remember" for the portal permission. Unfortunately there is not a whole lot we can do to force that. In general the permission model here is rather lacking. M +35 -17 server/SessionController.cpp M +10 -3 server/SessionController.h M +1 -2 server/main.cpp https://invent.kde.org/plasma/krdp/-/commit/8cea6fb883bb387c4d1adadad3bfe79b387c1abc
A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/37
Git commit 8d76d9a634d7072fdc1036bb2f2da45b5f8dd917 by Arjen Hiemstra. Committed on 13/06/2024 at 09:44. Pushed by ahiemstra into branch 'Plasma/6.1'. server: Create a single temporary portal session on server startup We want to ask the user for permission when it's convenient, not when there's nobody at the machine to confirm the permissions. So create a portal session at startup to request the permisisons. Unfortunately we cannot reuse this portal session since it leads to reconnection issues with the PipeWire stream. While that is probably solvable it also causes additional problems, most notably that the "Remote Desktop" SNI will be constantly active. So instead, discard the session after it was successfully started and create a new session when a new connection is incoming. This assumes the user checked "remember" for the portal permission. Unfortunately there is not a whole lot we can do to force that. In general the permission model here is rather lacking. (cherry picked from commit 8cea6fb883bb387c4d1adadad3bfe79b387c1abc) M +35 -17 server/SessionController.cpp M +10 -3 server/SessionController.h M +1 -2 server/main.cpp https://invent.kde.org/plasma/krdp/-/commit/8d76d9a634d7072fdc1036bb2f2da45b5f8dd917
As written, this bug report is fixed by that commit. We can refine the presentation later to not show any confirmation dialog at all, but at least the time when it's shown is immediate so it won't potentially block incoming unattended remote access requests.