Bug 481912

Summary: Feature request: Wayland remote login sessions with Plasma, like xrdp
Product: [Plasma] KRdp Reporter: Matthias Klumpp <matthias>
Component: generalAssignee: Unassigned bugs <unassigned-bugs-null>
Status: CONFIRMED ---    
Severity: wishlist CC: ahiemstra, alex, belzebu87, bugs.kde.org.facelift226, bugs.kde.org, dashonwwIII, glizda, jackyzy823, julien.dlq, kde.bugs, kde, klaus.kusche, kubry, matthias, michal, nate, nerumo, ngompa13, nicolas.fella, notmart, oded, oseker, serdarthtux, tagwerk19, unblended_icing552, wiagn233, yukicanis
Priority: NOR Keywords: wayland-only
Version First Reported In: 6.1.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Matthias Klumpp 2024-02-27 22:52:08 UTC
Hi everyone!
(I was asked to report the feature request here to keep track of it, since it affects multiple desktop components under Wayland)

I work at a research lab where we have very powerful servers connected to large data storage via a fast link. A lot of image processing as well as simulations are run on these machines, and it is incredibly convenient as people can take a working environment with them, and we also can share an expensive system extremely efficiently among many scientists.

This is how it is set up currently:
1. The user ssh-tunnels into the server they want to connect to (RDP ports are not exposed)
2. A RDP connection to xrdp[1] is created
3. xrdp-sesman[2], the session manager module of xrdp, creates a session for the user after authenticating them
4. Plasma/X11 is started for that user session and renders to the remote display, instead of an actual display

If a user disconnects, the session is kept running, and they get their session back as soon as they log in again. To terminate a session, the user has to log out explicitly.
We are also utilizing Apache Guacamole[3] to make this process even more convenient so people can avoid installing any additional software and get almost the same experience as if they were using e.g. Remmina[4] to connect remotely.

Of course, this complete workflow will not work at all when Plasma is running on Wayland, and XRDP, as the name suggests, is very X.org-specific (it is a fantastic tool though and serves us well).
In the long run it would be great if we could switch to Wayland and keep using Plasma (surprisingly, if stripped down just slightly Plasma is not much heavier than light desktops, and users like to use the desktop's tools, e.g. the Dolphin filemanager).

GNOME has a remote login in the works that looks similar to what XRDP provides and works on Wayland[5], but it would be fantastic if KDE could provide a similar feature.
Having any XDG portals or interactivity will not work - as soon as the user is authenticated, they should get a session noninteractively and there should not be a need to stay logged in for the session to continue to exist (the servers are headless, and if needed, the admin can always set session resource limits for users via logind).

A feature like this could for example be implemented by having a system service that takes incoming RDP connections and uses SDDM to authenticate and spawn a new Wayland session that can be interacted with using the transient seat protocol. Or if SDDM is too heavy, some lightweight service to handle the session authentication part.

In any case, this will require non-trivial work on a lot of components, and there's likely multiple ways to implement this feature (and it wouldn't even necessarily have to be RDP-based, but we found the protocol to be a bit more efficient than VNC in testing).

Thanks to everyone for the phantastic work on Plasma!
Cheers,
    Matthias

[1]: https://www.xrdp.org/
[2]: https://manpages.debian.org/testing/xrdp/xrdp-sesman.8.en.html
[3]: https://guacamole.apache.org/
[4]: https://remmina.org/
[5]: https://wiki.gnome.org/Initiatives/Wayland/Remoting#Remote_Login
Comment 1 Neal Gompa 2024-02-27 22:56:44 UTC
There's already the beginning steps toward this with KRdp: https://invent.kde.org/plasma/krdp
Comment 3 Nate Graham 2024-03-01 20:46:56 UTC
Yep, this is planned for Plasma 6.1, or maybe 6.2 if it slips.
Comment 4 unblended_icing552 2024-03-21 12:14:04 UTC
*** Bug 479500 has been marked as a duplicate of this bug. ***
Comment 5 Oded Arbel 2024-04-08 11:33:28 UTC
KRFB Desktop Sharing is an application that is part of the KDE software suite that shares the X11 or Wayland screen over VNC. It is mature and has worked well for me for a long time now. Maybe it will suite your needs as well - at least until KRDP is ready.
Comment 6 Dashon 2024-05-25 18:35:27 UTC
Arch has packaged krdp and it is now apart of the system settings. Can this be closed now?
Comment 7 Matthias Klumpp 2024-05-25 18:43:11 UTC
No, krdp does not work at all like xrdp yet. The whole session management part is missing (unless that has changed extremely recently) and you basically need to have physical access to the remote computer to make krdp viable.
Check out https://wiki.archlinux.org/title/xrdp and https://github.com/neutrinolabs/xrdp?tab=readme-ov-file#features
Comment 8 Klaus Kusche 2025-03-07 08:03:50 UTC
Same here. At my university, I currently run a headless linux terminal server for our students.
It currently uses xrdp to offer Xfce desktop sessions, but I'd like to move to KDE sooner or later.
RDP (not VNC) is a requirement.

Most important things needed:

* Virtual sessions, i.e. sessions for which no physical screen exists on the server.

* Multiple users at the same time, 
each user having his own independent desktop session, 
running with his permissions and his environment.

* User login and authentification using PAM.

* If a user disconnects, his session should be preserved
(except for sessions where the user explicitely logs out).
If a user logs in, he should be reconnected to his existing session if such a session exists.
Otherwise, a new session and desktop should be created for him.


Moreover, perhaps compression should be configurable:
The server has a high-bandwidth connection (10 Gbit),
but no or a very low-end graphics card (typical for servers).
So compressing 20 or 30 simultaneously connected user sessions 
could seriously suffer from CPU limitations
(I don't know what xrdp does, but it shows neither bandwidth nor CPU load problems).
Comment 9 Nate Graham 2025-05-09 17:26:32 UTC
*** Bug 423577 has been marked as a duplicate of this bug. ***
Comment 10 Robin Bankhead 2025-07-09 10:42:17 UTC
I have been looking for the same thing coming from the VNC camp, but I think this applies equally here as KRFB and KRDP have the same scoping limitation when it comes to supporting this feature (they are to be launched from inside an already-running session).

What KRFB does have, though I have not examined it, is the `krfb-virtualmonitor` utility which adds an output to an existing session using KWin's virtual backend. I will make an assumption that KRDP could utilise this backend as well (if anyone knows this is incorrect, please speak up.)

For either app to be able to do what we seek -- launch a session with a virtual display as its primary (sole) output -- work is needed on the `startplasma_wayland` (or presumably now this will simply be `startplasma`) script. I have a report for this here:

https://bugs.kde.org/show_bug.cgi?id=492285

There may be a chicken-and-egg flaw in this line of thought as my comprehension of the technologies involved is limited. If so, any clarifications are welcome.
Comment 11 Piotr Dobrogost 2025-07-09 17:49:30 UTC
(In reply to Robin Bankhead from comment #10)
> I have been looking for the same thing coming from the VNC camp, but I think

You might find the following blog posts by Arjen Hiemstra interesting (if you haven't already read them):
https://quantumproductions.info/articles/2023-08/remote-desktop-using-rdp-protocol-plasma-wayland
https://quantumproductions.info/articles/2024-06/krdp-plasma-61

I asked Arjen by email at ahiemstra [at] heimr.nl on June 27th if he could write another blog post about current status but with no answer so far. Btw, can anyone confirm if it's the right email address?

Generally I have a feeling that KDE devs could be sharing more information with users on directions and work being done (No, "This week in KDE" is not enough as it just lists recent changes without showing broader picture or going in depth like above posts).
Comment 12 Klaus Kusche 2025-07-19 14:51:12 UTC
Another requirement for full remote desktop usage, i.e. full xrdp replacement:
Support at least remote clipboard sharing and remote sharing of the client drives (filesystems) with the Microsoft Windows RDP client.
xrdp already does this for virtual X11 sessions, we successfully use it.

(at least for me, the other sharings, like sound sharing, printer sharing or usb device sharing, are not required).
Comment 13 Robin Bankhead 2025-07-19 18:04:36 UTC
(In reply to Klaus Kusche from comment #12)
> Another requirement for full remote desktop usage, i.e. full xrdp
> replacement:
> Support at least remote clipboard sharing and remote sharing of the client
> drives (filesystems) with the Microsoft Windows RDP client.
> xrdp already does this for virtual X11 sessions, we successfully use it.
> 
> (at least for me, the other sharings, like sound sharing, printer sharing or
> usb device sharing, are not required).

Something you might want to look into as a workaround: Weston has an RDP backend (uses FreeRDP)[1]. In theory you could run that (using the kiosk shell to be totally unobtrusive), and run the Plasma session nested inside that.

The Plasma session did work nested in Weston's (default) DRM backend; I tried its VNC backend but could not get it to work at all; I did not try the RDP backend, but if it works at all it should work for this technique.

(I did have success nesting Plasma inside Cage, and using WayVNC. The Plasma session works well, though Firefox causes some input dysfunction.)

Not wishing to drag this offtopic but thought the info might be helpful.

[1] https://man.archlinux.org/man/extra/weston/weston-rdp.7.en
Comment 14 Klaus Kusche 2025-07-20 07:53:01 UTC
(In reply to Robin Bankhead from comment #13)
> (In reply to Klaus Kusche from comment #12)
> > Another requirement for full remote desktop usage, i.e. full xrdp
> > replacement:
> > Support at least remote clipboard sharing and remote sharing of the client
> > drives (filesystems) with the Microsoft Windows RDP client.
> > xrdp already does this for virtual X11 sessions, we successfully use it.
> > 
> > (at least for me, the other sharings, like sound sharing, printer sharing or
> > usb device sharing, are not required).
> 
> Something you might want to look into as a workaround: Weston has an RDP
> backend (uses FreeRDP)[1]. In theory you could run that (using the kiosk
> shell to be totally unobtrusive), and run the Plasma session nested inside
> that.

Thank's for the hint.
As far as I can tell from the documentation, weston-rdp seems to lack the same features as Krdp:
- It does not provide any user and session management: 
It does not authenticate RDP logins using PAM and it does not switch session ownership to the RDP user.
- It does not seem to provide persistent sessions.
- I does not seem to provide clipboard and drive sharing with the client.
(as far as I know from xrdp, the server side of drive sharing is quite complex, requiring a fuse filesystem implementation).
Comment 15 Klaus Kusche 2025-07-21 08:51:51 UTC
Just some idea:
Why not write another plugin for xrdp instead of reinventing the wheel?
Xrdp handles the user authentication, it handles the session management,
it handles most parts of the RDP protocol including compression,
it handles most of the clipboard and local drive sharing, 
it handles audio redirection, ...

It would just require a driver plugin similar to xorgxrdp to connect the xrdp server to the wayland compositor.
Comment 16 Klaus Kusche 2025-07-22 15:11:22 UTC
... and it seems to be work in (slow) progress, see https://github.com/neutrinolabs/xrdp/issues/2637
Comment 17 Neal Gompa 2025-09-09 15:06:43 UTC
There has been some progress with KRdp gaining PAM support: https://invent.kde.org/plasma/krdp/-/merge_requests/123

We don't yet have things wired up to handle all the auth methods that FreeRDP+PAM support, I think.