SCP Protocol and future direction
This page applies to v0.9.15 of xrdp.
SCP is the name given to the protocol which xrdp and the SCP Utilities use to communicate with xrdp-sesman.
The protocol supports two versions:-
- V0 is a relatively simple protocol which allows xrdp to communicate sufficient parameters to xrdp-sesman to start (or reconnect to) a session.
- V1 implements a superset of the version 0 functionality. It provides additional management features which are used by the xrdp-sesadmin program.
The idea behind SCP V1 seems to have been to add a more capable protocol allowing for password changes, etc. SCP V0 was left 'as is', as SCP V1 was new and needed some work.
Most of the code for SCP is in the sesman/libscp directory in the distribution.
Although some SCP V0 client code is provided in this directory, it does not appear to be used. The xrdp daemon and xrdp-sesrun implement this functionality directly.
Provides a way to start sessions from the command line
Provides a session list function. A session kill function is sketched out, but not plumbed in.
A test-bed prototype for the V1 protocol. Not compiled by default.
This table is the result of some detective work performed in early 2021:-
| Date | Commit | Comment |
|---|---|---|
| 2006-11-24 | 078b4d3f | SCP V1 added along with the prototype sestest utility. |
| 2008-09-11 | 7c792986 | A management sub-protocol was added to SCP V1 along with xrdp-sesadmin. |
| <later> | <various> | Minor fixes, but no major changes in functionality. |
The original developer who made the commits above no longer appears to be on github. Since that time, no-one else has taken up the development or maintenance of SCP V1. There are a number of possible reasons for this:-
- SCP V1 is considerably more complex than V0. The introduction of the
pthreadlibrary suggests the original developer wanted to use threads withinxrdp-sesmanto provide a complete implementation. - A lot of the functionality for V1 is pitched at the wrong level. For example, a password-change mechanism does not need to be implemented here; rather the protocol should be providing a conduit for PAM to do this directly with the user. This approach would transparently support other functionality, like 2 factor authentication.
- The functionality does not solve real-world problems we have, like implementing reconnection and NLA
- The messages between processes are written using low-level primitives. No higher-level functions are available to make this process easier to implement and maintain.
In other words, we have acquired a large amount of overhead which is only really providing the session list functionality we have in xrdp-sesadmin
We have a significant issue with SCP V1 in that it is preventing a resolution of #1684. Fixing this fault is going to require a fairly major change to the way that authentication works in xrdp-sesman.
A tentative plan for resolving this is:-
- Remove the unused parts of the SCP V1 code from
libscp - Implement a fix to #1684
- Replace the remaining SCP code with something relatively lightweight and maintainable which can support features like:-
- PAM conversations
- Session reconnection
- NLA