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's authentication modules can be useful for:
- securing TCP sockets
- making the unix domain socket accessible to other users safely
- using the Proxy Server mode
For more information on the different types of connections, see wiki/Network.
The authentication module used is specified using the
Starting with version 0.15, there is also a
--tcp-auth=MODULE switch which allows a different authentication module to be used for TCP sockets.
In version 0.17, you can also use
--vsock-auth=MODULE for vsock (#983).
Here are the modules that can be used:
|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 (||alternative to file module||>=0.17|
|password||matches against a password given as a module option, ie: ||alternative to file module||>=0.17|
|multifile||matches usernames and passwords against an authentication file||proxy: see below||>=0.17|
|file||compares the password against the contents of a password file, see below||simple password authentication|
|pam||linux PAM authentication||Linux system authentication|
|win32||win32security authentication||MS Windows system authentication|
|system authentication||virtual module which will choose win32 or pam authentication automatically|
Version 0.17 introduces authentication module options so that each authentication module can specify options to configure its behaviour. The same module may be used with different types of sockets (tcp-auth vs auth), each with a different set of options. For more details see ticket:1159#comment:1.
XPRA_PASSWORD=mysecret xpra start --auth=env
SOME_OTHER_ENV_VAR_NAME=mysecret xpra start --auth=env:name=SOME_OTHER_ENV_VAR_NAME
xpra start --auth=password:value=mysecret
xpra start --auth=file:filename=/path/to/mypasswordfile.txt
xpra start --auth=multifile:filename=/path/to/userlist.txt
Beware when mixing environment variables and password files as the latter may contain a trailing newline character whereas the former often do not. The most common used option is the file / multifile filename option, see below.
In versions before 0.17, the password file could contain a single password or multiple usernames and passwords. This was confusing and error prone, which is why 0.17 has distinct modules for each use case: "file" and "multifile". See #1159 for details.
For more information on the multifile password file format, see proxy server file authentication.
The steps below assume that the client and server have been configured to use authentication:
- If the server is not configured for authentication, the client connection should be accepted but a warning will be printed
- If the client is not configured for authentication, the connection will fail with an authentication error
- This information applies to all clients: regular GUI clients as well as command line clients like "xpra info"
- Each authentication module specifies the type of password hashing it supports (usually HMAC)
- The "sys" authentication modules (pam and win32) require the actual password to be sent across to perform the authentication on the server - they therefore use the weak "xor" hashing
- You must use wiki/Encryption to be able to use "xor" hashing so that the password is protected during the exchange: the system will refuse to send "xor" hashed password unencrypted
- Encryption is processed before authentication
For more information on packets, see wiki/NetworkProtocol.
- All clients first send a hello packet to the server. If the client expects the server to request authentication for the connection, the client packet may omit most of the regular configuration information since a second packet will need to be sent. Until the server accepts the connection with its own hello packet response, the only packets that will be accepted by the clients are challenge and set_deflate (used to control packet compression). The client will exit unless the server responds within the
XPRA_SOCKET_TIMEOUTdelay + 10 seconds.
- The server sends back a challenge packet containing a random salt and the digest method to use as specified by the authentication module. If the client does not respond within the
XPRA_SOCKET_TIMEOUTdelay (defaults to 10 seconds), it is disconnected. The only packets that will be accepted by the server until the client has successfully authenticated are hello and disconnect.
- The client generates its own random salt and responds with a new "hello" packet containing the challenge response (the hashed password and the client salt used), the client and server salts are combined with "xor" before hashing the password. (so there is no way for the server to predict the actual salt used at all)
- When the server receives the hello packet containing the challenge response, it hands it over to the authentication module, which can then:
- with hmac: verify that it obtains the same hash by combining its own password value with the two salts
- with xor: xor the password again with the two salts to retrieve the original password value
- when used over TCP sockets, password authentication is vulnerable to man-in-the-middle attacks where an attacker could intercept the initial exchange and use the stolen authentication challenge response to access the session, Encryption prevents that
- the client does not verify the authenticity of the server, Encryption does
authwiki/Logging may leak some authentication information
- if you are concerned about security, use SSH as transport instead