Xpra’s authentication modules can be useful for: * securing socket connections * making the unix domain socket accessible to other users safely * using the proxy server
For more information on the different types of connections, see network
SSL mode can also be used for authentication using certificates (see #1252)
When using SSH to connect to a server, encryption and authentication can be skipped: by default the unix domain sockets used by ssh do not use authentication.
Xpra supports many authentication modules. Some of these modules require extra dependencies.
Here is the full list:| Module | Result | Purpose |
|---|---|---|
| allow | always allows the user to login, the username used is the one supplied by the client | dangerous / only for testing |
| none | always allows the user to login, the username used is the one the server is running as | dangerous / only for testing |
| fail | always fails authentication, no password required | useful for testing |
| reject | always fails authentication, pretends to ask for a password | useful for testing |
| env | matches against an environment variable (XPRA_PASSWORD
by default) |
alternative to file module |
| password | matches against a password given as a module option, ie:
auth=password:value=mysecret |
alternative to file module |
| multifile | matches usernames and passwords against an authentication file | proxy: see password-file below |
| file | compares the password against the contents of a password file, see password-file below | simple password authentication |
| pam | linux PAM authentication | Linux system authentication |
| win32 | win32security authentication | MS Windows system authentication |
sys |
system authentication | virtual module which will choose win32 or pam authentication automatically |
| sqlite | sqlite database authentication | #1488 |
| peercred | SO_PEERCRED authentication |
|
| tcp hosts | TCP Wrapper | #1730 |
| exec | Delegates to an external command | #1690 |
| kerberos-password | Uses kerberos to authenticate a username + password | #1691 |
| kerberos-ticket | Uses a kerberos ticket to authenticate a client | #1691 |
| gss_auth | Uses a GSS ticket to authenticate a client | #1691 |
| ldap | Uses ldap via python-ldap | #1791 |
| ldap3 | Uses ldap via python-ldap3 | #1791 |
| u2f | Universal 2nd Factor | #1789 |
Starting with version 4.0, the preferred way of specifying
authentication is within the socket option itself.
ie for starting a seamless server with a
TCP socket protected by a password stored in a file:
xpra start --start=xterm -d auth
--bind-tcp=0.0.0.0:10000,auth=file:filename=password.txt
So that multiple sockets can use different authentication modules, and those modules can more easily be chained:
xpra start --start=xterm -d auth \
--bind-tcp=0.0.0.0:10000,auth=hosts,auth=file:filename=password.txt --bind
--bind-tcp=0.0.0.0:10001,auth=sys
XPRA_PASSWORD=mysecret xpra start --bind-tcp=0.0.0.0:10000,auth=envSOME_OTHER_ENV_VAR_NAME=mysecret xpra start --bind-tcp=0.0.0.0:10000,auth=env:name=SOME_OTHER_ENV_VAR_NAMExpra start --bind-tcp=0.0.0.0:10000,auth=password:value=mysecretxpra start --bind-tcp=0.0.0.0:10000,auth=file:filename=/path/to/mypasswordfile.txtxpra start --bind-tcp=0.0.0.0:10000,auth=sqlite:filename=/path/to/userlist.sdbThe syntax with older versions used a dedicated switch for each
socket type: * --auth=MODULE for unix domain sockets and
named pipes * --tcp-auth=MODULE for TCP sockets *
--vsock-auth=MODULE for vsock (#983) etc
file module, the password-file contains a
single password, the whole file is the password (including any trailing
newline characters). To write a password to a file without the trailing
newline character, you can use
echo -n "thepassword" > password.txtmultifile, the password-file contains a list of
authentication values, see proxy server -
this module is deprecated in favour of the sqlite module
which is much easier to configurexpra attach tcp://username:password@host:port/
for connecting to the TCP socket and specifying the
password only:
xpra attach tcp://:password@host:port/
Since the username is ignored, it can also be replaced with any string of your liking, ie ‘foobar’:
xpra attach tcp://foobar:password@host:port/
Only the following modules will make use of both the username and
password to authenticate against their respective backend:
kerberos-password, ldap, ldap3,
sys (pam and win32),
sqlite, multifile and u2f. In
this case, using an invalid username will cause the authentication to
fail.
The username is usually more relevant when authenticating against a proxy server (see authentication details there).
challenge-handlers
option, by default the client will try the following handlers in the
specified order: uri (whatever password may have been
specified in the connection string), file (if the
password-file option was used), env (if the
environment variable is present), kerberos,
gss, u2f and finally prompt
xpra infopam, win32,
kerberos-password, ldap and
ldap3) require the actual password to be sent across to
perform the authentication on the server - they therefore use the weak
xor hashing, which is insecurexor hashing so that the password is
protected during the exchange: the system will refuse to send a
xor hashed password unencryptedauth debug
logging may leak some authentication information