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:list of modules
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
more examples
XPRA_PASSWORD=mysecret xpra start --bind-tcp=0.0.0.0:10000,auth=env
SOME_OTHER_ENV_VAR_NAME=mysecret xpra start --bind-tcp=0.0.0.0:10000,auth=env:name=SOME_OTHER_ENV_VAR_NAME
xpra start --bind-tcp=0.0.0.0:10000,auth=password:value=mysecret
xpra start --bind-tcp=0.0.0.0:10000,auth=file:filename=/path/to/mypasswordfile.txt
xpra start --bind-tcp=0.0.0.0:10000,auth=sqlite:filename=/path/to/userlist.sdb
syntax for older versions
The 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.txt
multifile
, 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 configuretcp example
xpra attach tcp://username:password@host:port/
example: specifying the password only
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).
Authentication Process
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
module and platform specific notes
xpra info
pam
, 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 informationSalt handling is important