xpra icon
Bug tracker and wiki

Opened 21 months ago

Last modified 3 weeks ago

#2125 new enhancement

let a server register with a proxy

Reported by: brief Owned by: brief
Priority: major Milestone: 4.1
Component: network Version: 2.4.x
Keywords: Cc: mjharkin@…

Description

If a server has the ability to register on a proxy, the proxy can become aware of servers where discovery via bonjour is not possible.

Furthermore, this allows hole punching in the servers firewall if the server is keeping the connection to the proxy alive. This allows to have client and server behind a NAT and only needs a proxy exposed.

Attachments (4)

command line options.patch (6.3 KB) - added by brief 20 months ago.
paket handler.patch (3.7 KB) - added by brief 20 months ago.
evolve.patch (15.4 KB) - added by brief 7 months ago.
8d6c8c863e1a97162f1c49598ffeb4cfde96e9c5.patch (40.8 KB) - added by brief 4 weeks ago.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 21 months ago by Antoine Martin

Milestone: 2.53.0
Owner: changed from Antoine Martin to brief

How would a client identify which server it wants to connect to?

The standard way of doing this at the moment is using sqlite auth (#1488), which you can already use today as long as the server is not behind NAT: the servers can add themselves to the sqlite auth database used by the proxy to locate sessions for its users.

To workaround the NAT problem, the servers would need to connect to the proxy instead of the other way around.
The connection would have to be authenticated and then kept alive until a client takes over.
This is quite similar to #1022.

comment:2 Changed 21 months ago by Antoine Martin

Component: corenetwork
Owner: changed from brief to Antoine Martin
Status: newassigned
Summary: let a server register at a proxylet a server register with a proxy

Add a new command line option so that servers can advertise themselves to remote proxy servers.
This would complement wiki/MulticastDNS and make it easier to deploy proxy servers.
Can also be used for easy NAT traversal: both server and client can be behind NAT.

Related tickets:

  • #1590 network tracker ticket
  • #675 extend xpra proxy for terminal server deployments

ie:

xpra start --start=xterm \
    --register=tcp://proxyusername:proxypassword@proxyip:proxyport/SESSIONID?\
    username=optionalclientloginusername&password=optionalclientloginpassword

Issues:

  • only allow registration on some tcp / ws / wss / ssh sockets?
  • support multiple proxies: register with all of them, or the first one, or random, or...
  • re-connect to the proxy if the connection drops, maybe add an option to give up and exit if none of the proxies are available for too long
  • keep connection to proxy alive - also similar to #1022: "client listen mode"
  • the proxy needs to keep track of those sessions in memory, return them before or after the ones from the client auth module?
  • the proxy servers could also listen for mdns broadcasts and expose those servers

comment:3 Changed 20 months ago by brief

I tried to do changes regarding this ticket, but I got stuck after implementing the command line options.

I suggest using one command line option for the server to register himself at a proxy and one command line option for the proxy to accept registrations.

The option for the server could be like yours above. Multiple --register options could be accepted, each with a list of servers. Connections are made to a random not failing entry in each list. Thus multiple proxies with failover configurations can be configured.

The option for the proxy should include the protocol to listen on.

Should there be a new table containing optionalclientloginusernames and passwords with groups matched to users group?

comment:4 Changed 20 months ago by Antoine Martin

I tried to do changes regarding this ticket, but I got stuck after implementing the command line options.

Where is your code?

The option for the proxy should include the protocol to listen on.

I think this should be done as per #1160, using chained authentication modules: the last module in the chain would do the registration.

Should there be a new table containing optionalclientloginusernames and passwords with groups matched to users group?

Not sure I understand, I don't think anything should be tied to unix user groups. The solution should be generic.

Changed 20 months ago by brief

Attachment: command line options.patch added

Changed 20 months ago by brief

Attachment: paket handler.patch added

comment:5 Changed 20 months ago by brief

I attached a patch regarding the command line options. The cmd options are not in the format you mentioned but in the old one.

I also attached a patch what I tried with a new paket handler, but I certainly sure this is not the right way to do it.

Regarding optionalclientloginusernames: I understood that a server willing to register at a proxy can provide credentials (optionalclientloginusernames, optionalclientloginpassword). I wanted to ask if a new table in db/... is needed (e.g. server_users) to store these combinations. Furthermore I thought about the idea, to be able to indicate groups at server_users to be able to present users a list of servers matching by group.

comment:6 Changed 20 months ago by Antoine Martin

Owner: changed from Antoine Martin to brief
Status: assignednew
  • there is no authentication on the "register" packets? You would be better off using a hello request option. (see how detach or info requests are handled)
  • if using a dedicated packet type, the "register" packet handler should live in the proxy code, not in server core module.
  • I don't understand why you're using mod_python here
  • the "answer" object is constructed weird and I don't see the code for add_user anywhere
  • the register string should be a regular xpra URI (ie for TCP: tcp://username:password@host:port/?extra_args), that way authentication will be handled automatically

comment:7 Changed 19 months ago by Antoine Martin

See also #2261

comment:9 Changed 18 months ago by Antoine Martin

Owner: changed from brief to Antoine Martin
Status: newassigned

Here's my plan - feel free to comment:

  • --proxy-sessions=auth,sys,mdns,register so the proxy can be told where to get the list of sessions from (and maybe those options can be combined?):
    • auth (default) would still use the auth module so we don't break any existing setups
    • sys same as what most auth modules currently do: similar to running xpra list using the same uid supplied by the auth module (usually the user that authenticated)
    • mdns without knowing if the server already has clients or not since we can't seem to get TXT record update notifications (see #2187)
    • register get the list of sessions from servers that register with the proxy
  • I would like to re-use all the socket code and authentication configuration options for the server registration (so servers can use ssl / ssh / whatever), but ideally without letting the servers have the same privileges as regular authenticated users (ie: no ability to connect to sessions or start new sessions, just registering) - not sure how to do that yet (comment:4 suggested using a new authentication module, but this would be too difficult to tie with other features: keepalive, etc), should this be configured at the socket level (as part of the --bind-XXXX option), or as part of the authentication module? (ie: access=full,register,info,... to specify what the authentication gives access to)
  • the sessions can be identified using their uuid, and maybe other attributes? the display string is not a good match as multiple servers running on different systems can use the same display number. uids are not usually portable either (not without things like ldap - which we can't require)
  • the server code will need a new option for telling it to register with the proxy, something like: --register=tcp://host:port/?options, it will need options like keepalive and re-connect, we should detect authentication failures and not retry too often in that case
  • the proxy can keep these connections open, proxy_auth can be taught about the special "registered" sessions and bypass connect_to

Notes:

  • do we want to think about load-balancing?
  • how do we select a session easily?
  • if more than one is available?

comment:10 Changed 18 months ago by Antoine Martin

Cc: mjharkin@… added

(CC was removed by mistake)

comment:11 Changed 14 months ago by Antoine Martin

Some useful socket functions have been moved:

  • r23736 refactoring: move code to socket_util
  • r23737 move socket_util to xpra.net
  • r23738 make add_listen_socket more re-usable
  • r23740 remove socket_types mapping, use callback argument instead
  • r23741 move accept_connection code to socket_util

comment:12 Changed 14 months ago by Antoine Martin

More network related updates that can help here:

  • r23742 + r23756: cosmetic
  • r23747 assume socket if path is given as display
  • r23748 control channel fix for python3 proxy instances
  • r23750 : #2408
  • r23754 warn if a unix domain socket goes MIA
  • r23759 cleanup now stops listening for socket events, fix r23740 (must return True to continue receiving socket events)
  • r23760 BUG introduced by r23759, cleanup IO event source only once
  • r23761 simplify named-pipe extra "pipe_handle" argument (make it a default arg)
  • r23762 : #2407
  • r23763 : proxy instance process message queue cleanup
  • r23768 refactor peek_connection to make it reusable
  • #1022 : client listen mode
  • r23769 constify
Last edited 14 months ago by Antoine Martin (previous) (diff)

comment:13 Changed 14 months ago by Antoine Martin

Milestone: 3.04.0

Too late for 3.0, will deal with this after #1160 so we can re-use the same bind-XXX syntax and have different capabilities on different ports.

comment:14 in reply to:  9 Changed 7 months ago by brief

  • --proxy-sessions=auth,sys,mdns,register so the proxy can be told where to get the list of sessions from (and maybe those options can be combined?):

Combining seems like a good idea.

  • the sessions can be identified using their uuid, and maybe other attributes? the display string is not a good match as multiple servers running on different systems can use the same display number. uids are not usually portable either (not without things like ldap - which we can't require)

The server could send its desired display name, e.g. "Facility 7, Room 5" and forwarded application. Furthermore, the session is tied to a proxy user (from e.g. server_users, see above(and could be shared with a proxy_group)). Clients requesting sessions from the proxy are only getting their accessible sessions, thus the displayname has limited scope.

  • do we want to think about load-balancing?

To balance register/list requests? Or to balance connections between client and server in TURN mode?

  • how do we select a session easily?
  • if more than one is available?

A session has to be selected choosen from prior requested list of accessible sessions.

  • only allow registration on some tcp / ws / wss / ssh sockets?

Allow on all specified authenticators?

  • support multiple proxies: register with all of them, or the first one, or random, or...

Take a xpraUri[][] as proxies. Server will connect to one of each inner in all outer.

  • the proxy needs to keep track of those sessions in memory, return them before or after the ones from the client auth module?

Can they be stored using the Authenticator?

  • the proxy servers could also listen for mdns broadcasts and expose those servers

Are mdns broadcast receivable via client packets?

  • I would like to re-use all the socket code and authentication configuration options for the server registration (so servers can use ssl / ssh / whatever), but ideally without letting the servers have the same privileges as regular authenticated users (ie: no ability to connect to sessions or start new sessions, just registering) - not sure how to do that yet (comment:4 suggested using a new authentication module, but this would be too difficult to tie with other features: keepalive, etc), should this be configured at the socket level (as part of the --bind-XXXX option), or as part of the authentication module? (ie: access=full,register,info,... to specify what the authentication gives access to)

Is this still a problem?

  • the server code will need a new option for telling it to register with the proxy, something like: --register=tcp://host:port/?options, it will need options like keepalive and re-connect, we should detect authentication failures and not retry too often in that case

I would consider to specify a list of proxies where keep-alive packet are send to (including a token). Registering using credentials should be a one time (interactive) action to get a token.

Last edited 7 months ago by brief (previous) (diff)

Changed 7 months ago by brief

Attachment: evolve.patch added

comment:15 in reply to:  9 Changed 7 months ago by brief

Replying to Antoine Martin:

  • I would like to re-use all the socket code and authentication configuration options for the server registration (so servers can use ssl / ssh / whatever), but ideally without letting the servers have the same privileges as regular authenticated users (ie: no ability to connect to sessions or start new sessions, just registering) - not sure how to do that yet (comment:4 suggested using a new authentication module, but this would be too difficult to tie with other features: keepalive, etc), should this be configured at the socket level (as part of the --bind-XXXX option), or as part of the authentication module? (ie: access=full,register,info,... to specify what the authentication gives access to)

How much does the patch above hurt your eyes? It seems like an option to divide traffic in the proxy_auth and let the authenticator handle DB/memory specific things. I mocked it up in the proxy_auth function, this could also go in a different class.

Is there any way I can create a branch? Or is uploading patches the way to go?

comment:16 Changed 6 months ago by Antoine Martin

Milestone: 4.04.1

How much does the patch above hurt your eyes?

The patch is not too bad, but I'm out of time.

I've done some work on generalizing bind command line options in #2406.
This needs extending.

comment:17 Changed 4 weeks ago by brief

I rewrote the patch to use a hello request type for register and update requests.

Start a proxy with register/update support:

proxy --tcp-auth=sqlite:filename=userlist.sdb --proxy-sessions=register --bind-tcp=127.0.0.1:10009

Add a session at the proxy which returns a token to update the session:

xpra register tcp://username:password@127.0.0.1:10009/

Start a server and update the session at the proxy:

xpra start --start=xterm --bind-tcp=127.0.0.1:10010 --proxies=tcp://127.0.0.1:10009/update_token=SESSION_TOKEN

I have only tested it with sqlite, it only works with sqlite atm (scripts/server.py:427).
It seems verify_auth in the core has to handle the update request and call auth_verified (server_core.py:1670).

Perhaps you can help me with the following:

  • How do I get options for a client request in main.py:555? What should they contain except the token?
  • Is this method of creating a client generally correct? (main.py:586-603)
  • Is it possible to access the request arguments (token) in proxy_server:680?
  • Is there a better way of checking if an sql auth is given than in scripts/server.py:427?

comment:18 Changed 4 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to brief
Status: assignednew

Can you explain why you need to register the session first?
Doesn't it make sense to just let the server register with the proxy without needing to register first? What's the benefit?

This registration ability should be an attribute of the authentication modules - see #2424.
So you could enable this on a specific port (DMZ), and not on another (WAN), ie:

--bind-tcp=127.0.0.1:10009,auth=file:filename=server-auth,auth=sqlite:filename=userlist.sdb:register=1 \
--bind-tcp=0.0.0.0:10000,auth=sqlite:filename=userlist.sdb:register=0

In this example: the registration requires password authentication using file auth before you can add entries to the sqlite db, clients connect to port 10000 and only need to authenticate with sqlite.
The registration would only be implemented in the generic sql backend for now - the other modules would just fail when calling proxy_register / proxy_update.


Not essential, but it would be nice of the server maintained the connection to the proxy:

  • the proxy could automatically remove the session when the server disconnects
  • the proxy would not need to connect back to the server when a client claims the session, it could just re-use the connection

I've merged the 2 whitespace changes.
I think that most of the changes to sqlauthbase.py and sqlite_auth.py would be worth merging without the rest as it would reduce the diff when reviewing. (just without the token / session_add stuff for now)

As for the remainder of your questions, the line numbers don't match trunk?

comment:19 in reply to:  18 Changed 4 weeks ago by brief

Replying to Antoine Martin:

Can you explain why you need to register the session first?

For authenticated updates (server -> proxy), an authentication mechanism must be present. Since servers are mostly non-interactive (daemon), any credentials need to be stored in the config file or as parameter. Storing a token which can only update one session at the proxy prevents storing usernames/passwords and limits the abilities of stolen tokens.

Doesn't it make sense to just let the server register with the proxy without needing to register first? What's the benefit?

With the DB schema from the patch, one user can have multiple sessions. Only with username/password, no session to update can be identified. If the identifier can be chosen freely by the client, uniqueness is not guaranteed.

Registering is a one-time action per server (upon installing/setting up xpra), updates are sent periodically while the server is running.

This registration ability should be an attribute of the authentication modules - see #2424.
So you could enable this on a specific port (DMZ), and not on another (WAN), ie:

--bind-tcp=127.0.0.1:10009,auth=file:filename=server-auth,auth=sqlite:filename=userlist.sdb:register=1 \
--bind-tcp=0.0.0.0:10000,auth=sqlite:filename=userlist.sdb:register=0

In this example: the registration requires password authentication using file auth before you can add entries to the sqlite db, clients connect to port 10000 and only need to authenticate with sqlite.
The registration would only be implemented in the generic sql backend for now - the other modules would just fail when calling proxy_register / proxy_update.

So there is a need for another option which enables registering (and updating) selectively by auth backend.

Not essential, but it would be nice of the server maintained the connection to the proxy:

  • the proxy could automatically remove the session when the server disconnects
  • the proxy would not need to connect back to the server when a client claims the session, it could just re-use the connection

I agree that the server should keep the connection alive. But the proxy should not delete the session because it is possibly updated later. I thought to fill the "updated" field with a timestamp of the last update, but a flag "currently connected" is also possible.
I reused the sessions table to also store "registered servers".

As for the remainder of your questions, the line numbers don't match trunk?

The line numbers match revision 27551 with 8d6c8c863e1a97162f1c49598ffeb4cfde96e9c5.patch​ applied.

comment:20 Changed 3 weeks ago by Antoine Martin

For authenticated updates (server -> proxy), an authentication mechanism must be present.

Yes, that's why I proposed: --bind-tcp=127.0.0.1:10009,auth=file:filename=server-auth,auth=sqlite:filename=userlist.sdb:register=1 for the socket which is facing the servers. I used file as an example but you could use sqlite for that too.
Using tokens makes things more complicated. We have multi-layer authentication support, let's use it.

Storing a token which can only update one session at the proxy prevents storing usernames/passwords and limits the abilities of stolen tokens.

The only gain here is the ability to restrict to one session, not sure how useful that is in practice.

With the DB schema from the patch, one user can have multiple sessions.
Only with username/password, no session to update can be identified.
If the identifier can be chosen freely by the client, uniqueness is not guaranteed.

OK, or you could just use different username + password combinations for each session.

Registering is a one-time action per server (upon installing/setting up xpra), updates are sent periodically while the server is running.

Hmm. Then if the server drops off, the session will be unreachable.
And the proxy has to make a new connection to the server.

The registration would only be implemented in the generic sql backend for now - the other modules would just fail when calling proxy_register / proxy_update.

So there is a need for another option which enables registering (and updating) selectively by auth backend.

Yes. It is much safer that way.

The line numbers match revision 27551 with 8d6c8c863e1a97162f1c49598ffeb4cfde96e9c5.patch​ applied.

Can you please post easy to parse links, maybe just code extracts.
And please submit things separately: most of the DatabaseBaseQueries could be merged without the rest. (though I do wonder the point of having QueriesBase - doubles the size of the code without any visible benefits)

Note: See TracTickets for help on using tickets.