authentication modules refactoring

[Antoine Martin]

This is a tracker ticket for some changes already committed to trunk.
Related to #983, #1133 and #1150. See also #888.

• r10848 + r11962: debugging improvements
• r11465 + r12142: sanity checks, remove legacy options (may be partially reverted for #1133)
• r12037: splits the file authentication module into two:
  • "file" which contains a single password
  • "multifile" which contains the multiline username+password format more commonly used with the proxy server
• r12083 + r12084 py3k compat
• r12219: named pipes support (#1150)

[Antoine Martin]

Final (?) touches in r12332.
We also have some new authentication modules in r12334:

• env which looks up the password using the environment variable specified (defaults to XPRA_PASSWORD), ie: XPRA_PASSWORD=mysecret xpra start --auth=env or SOME_OTHER_ENV_VAR_NAME=mysecret xpra start --auth=env:name=SOME_OTHER_ENV_VAR_NAME
• password which specifies the password directly (on the command line - which is a bit dangerous, or in a config file), ie: --auth=password:value=mysecret

I have added this information to wiki/Authentication.

---

What the changes in r12332 mean is that we should no longer use password-file server side. That's because we have auth, tcp-auth and vsock-auth but only one password-file option. It will still work for now as fallback, but won't be supported and will eventually be removed in a future release.

The "new and improved" way is to configure per-socket type authentication is:

xpra start --start-child="xterm" \
    --bind=/path/to/sockdir  --auth=file:filename=`pwd`/password.txt \
    --bind-tcp=0.0.0.0:10000 --tcp-auth=file:filename=`pwd`/tcp-password.txt \
    --bind-vsock=auto:2000   --vsock-auth=file:filename=`pwd`/vsock-password.txt

Notes:

• we don't actually need to set bind=/path/to/sockdir because the default config has one already, but I think it makes this example clearer showing them all as pairs
• if you specify an auth module but no corresponding socket, we just ignore it and nothing happens (ie: "tcp-auth" without a "bind-tcp")
• we can also use auth=none or whatever for any of those auth options, as before
• we still default to using tcp-auth=auth if no module is specified for tcp, this is to ease the transition from older versions which did not have tcp-auth at all
• ideally, in the future we can do #1160 too

Things this may break / cause problems with:

• authentication (obviously)
• proxy server
• printing

[alas]

Hmm... can't seem to get this syntax to connect.

Windows client 1.0 r13101. Fedora 23 sever 1.0 r13370.

Server side I set up a password file and then tried to use it:

[jimador@jimador ticket1159]$ echo "bob" > tcp-password.txt
[jimador@jimador ticket1159]$ cat tcp-password.txt
bob
[jimador@jimador ticket1159]$ xpra --no-daemon --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --tcp-auth=file:filename=/home/jimador/ticket1159/tcp-password.txt -d auth

Client side, I tried:

C:\Program Files (x86)\Xpra>echo bob > \Users\hassenpfeffer\password.txt

C:\Program Files (x86)\Xpra>type \Users\hassenpfeffer\password.txt
bob

C:\Program Files (x86)\Xpra>Xpra_cmd.exe attach tcp:10.0.32.134:1203 --password-file=\Users\hassenpfeffer\password.txt -d auth

The server output is warning about a socket not being successfully created, which I don't think should be causing a problem, but it indicates that the authentication is failing:

No pam support: No module named pam

X.Org X Server 1.18.3
Release Date: 2016-04-04
X Protocol Version 11, Revision 0
Build Operating System:  4.4.9-300.fc23.x86_64
Current Operating System: Linux jimador.plata 4.4.9-300.fc23.x86_64 #1 SMP Wed May 4 23:56:27 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.4.9-300.fc23.x86_64 root=UUID=7dc8a1f0-603b-4d33-9f61-95ee93330923 ro rhgb quiet LANG=en_US.UTF-8
Build Date: 30 June 2016  11:04:38PM
Build ID: xorg-x11-server 1.18.3-3.fc23
Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/var/run/user/1001/xpra/Xorg.:13.log", Time: Tue Aug 16 17:14:41 2016
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2016-08-16 17:14:42,306 created unix domain socket: /var/run/user/1001/xpra/jimador.plata-13
2016-08-16 17:14:42,306 created unix domain socket: /home/jimador/.xpra/jimador.plata-13
2016-08-16 17:14:42,307 Warning: cannot create socket '/var/run/xpra/jimador.plata-13'
2016-08-16 17:14:42,307  [Errno 13] Permission denied (missing group membership?)
2016-08-16 17:14:43,016 serving html content from '/usr/share/xpra/www'
2016-08-16 17:14:43,017 get_auth_module(unix-domain, , {..})
2016-08-16 17:14:43,017 get_auth_module(tcp, file:filename=/home/jimador/ticket1159/tcp-password.txt, {..})
2016-08-16 17:14:43,059 get_auth_module(ssl, file:filename=/home/jimador/ticket1159/tcp-password.txt, {..})
2016-08-16 17:14:43,060 get_auth_module(vsock, , {..})
2016-08-16 17:14:43,060 init_auth(..) auth class=None, tcp auth class=('file', <class 'xpra.server.auth.file_auth.Authenticator'>, {'filename': '/home/jimador/ticket1159/tcp-password.txt'}), ssl auth class=('file', <class 'xpra.server.auth.file_auth.Authenticator'>, {'filename': '/home/jimador/ticket1159/tcp-password.txt'}), vsock auth class=None
2016-08-16 17:14:43,146 2.0GB of system memory
2016-08-16 17:14:43,154 Warning: webcam forwarding is disabled
2016-08-16 17:14:43,155  the virtual video directory '/sys/devices/virtual/video4linux' was not found
2016-08-16 17:14:43,155  make sure that the 'v4l2loopback' kernel module is installed and loaded
2016-08-16 17:14:43,155 found 0 virtual video devices for webcam forwarding
2016-08-16 17:14:43,164 pulseaudio server started with pid 2208
2016-08-16 17:14:43,329 GStreamer version 1.6 for Python 2.7 64-bit
2016-08-16 17:14:43,393 D-Bus notification forwarding is available
2016-08-16 17:14:43,405 started command 'xterm' with pid 2220
2016-08-16 17:14:43,405 xpra X11 version 1.0-r13370 64-bit
2016-08-16 17:14:43,406  running with pid 2112 on Linux Fedora 23 TwentyThree
2016-08-16 17:14:43,406  connected to X11 display :13
xterm: cannot load font '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
2016-08-16 17:14:43,473 xpra is ready.
2016-08-16 17:14:43,526 printer forwarding enabled using postscript and pdf
2016-08-16 17:15:45,662 New tcp connection received from 10.0.11.162:54370
2016-08-16 17:15:45,666 socktype=tcp, auth class=('file', <class 'xpra.server.auth.file_auth.Authenticator'>, {'filename': '/home/jimador/ticket1159/tcp-password.txt'}), encryption=, keyfile=
2016-08-16 17:15:45,670 creating authenticator ('file', <class 'xpra.server.auth.file_auth.Authenticator'>, {'filename': '/home/jimador/ticket1159/tcp-password.txt'})
2016-08-16 17:15:45,678 file=password file
2016-08-16 17:15:45,678 processing authentication with password file, response=None, client_salt=, challenge_sent=False
2016-08-16 17:15:45,679 challenge: ('710dbd35d091483493815917a4dc51df26a79b15403e479aaa6f1c32313c6e55', 'hmac')
2016-08-16 17:15:45,679 Authentication required by password file authenticator module
2016-08-16 17:15:45,679  sending challenge for 'hassenpfeffer' using hmac digest
2016-08-16 17:15:45,714 processing authentication with password file, response=37a8363898a9ef9f03bc9a48927ffc7f, client_salt=31636537323763316636633634363139386265613461323062323062626431333166613330333439396236323436323538323739643639663832666537333464, challenge_sent=True
2016-08-16 17:15:45,715 mtime(/home/jimador/ticket1159/tcp-password.txt)=1471392712.85
2016-08-16 17:15:45,715 loaded 4 bytes from '/home/jimador/ticket1159/tcp-password.txt'
2016-08-16 17:15:45,715 authenticate(37a8363898a9ef9f03bc9a48927ffc7f) password=bob
, hex(salt)=065255535053500402065a07000e020d01515d50015803070306540157555555035000040951050c0d52055700010b545953015f55550a540b03550601560151, hash=6e371873febef509dee7fdce3394338a
2016-08-16 17:15:45,716 expected '6e371873febef509dee7fdce3394338a' but got '37a8363898a9ef9f03bc9a48927ffc7f'
2016-08-16 17:15:45,716 Error: hmac password challenge for 'hassenpfeffer' does not match
2016-08-16 17:15:45,716 Error: authentication failed
2016-08-16 17:15:45,716  invalid challenge response
2016-08-16 17:15:46,718 Disconnecting client 10.0.11.162:54370:
2016-08-16 17:15:46,718  invalid challenge response

Client-side I'm not seeing anything that seems relevant, but maybe you'll see something:

2016-08-16 17:15:44,115 Xpra gtk2 client version 1.0-r13101 32-bit
2016-08-16 17:15:44,118  running on Microsoft Windows 8.1
2016-08-16 17:15:44,408 GStreamer version 1.6 for Python 3.4 32-bit
2016-08-16 17:15:44,887 OpenGL_accelerate module loaded
2016-08-16 17:15:45,137 processing challenge: ['710dbd35d091483493815917a4dc51df26a79b15403e479aaa6f1c32313c6e55', '', 'hmac']
2016-08-16 17:15:45,138 hmac(626f62200d0a, 065255535053500402065a07000e020d01515d50015803070306540157555555035000040951050c0d52055700010b545953015f55550a540b03550601
560151)=37a8363898a9ef9f03bc9a48927ffc7f
2016-08-16 17:15:45,140  detected keyboard: layout=us
2016-08-16 17:15:45,141  desktop size is 5120x2160 with 1 screen:
2016-08-16 17:15:45,141   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2016-08-16 17:15:45,141     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2016-08-16 17:15:45,141     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x638
2016-08-16 17:15:45,142  upscaled by 167%, virtual screen size: 3072x1296
2016-08-16 17:15:45,142   Default (1354x571 mm - DPI: 57x57) workarea: 3072x1272
2016-08-16 17:15:45,144     DISPLAY1 2304x1296 at 768x0 (621x341 mm - DPI: 94x96) workarea: 2304x1272
2016-08-16 17:15:45,144     DISPLAY2 768x432 (597x336 mm - DPI: 32x32) workarea: 768x383
2016-08-16 17:15:46,176 server failure: disconnected before the session could be established
2016-08-16 17:15:46,176 server requested disconnect: invalid challenge response
2016-08-16 17:15:46,188 Connection lost

Trying to launch the server with the env explicitly set, as mentioned above, I get the same result.

 XPRA_PASSWORD=bob xpra --no-daemon --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --tcp-auth=env -d auth

And client connection with the same Xpra_cmd.exe attach tcp:10.0.32.134:1203 --password-file=\Users\hassenpfeffer\password.txt -d auth...

Server output that looks mildly different:

2016-08-16 17:46:59,409 get_auth_module(unix-domain, , {..})
2016-08-16 17:46:59,409 get_auth_module(tcp, env, {..})
2016-08-16 17:46:59,428 get_auth_module(ssl, env, {..})
2016-08-16 17:46:59,428 get_auth_module(vsock, , {..})
2016-08-16 17:46:59,428 init_auth(..) auth class=None, tcp auth class=('env', <class 'xpra.server.auth.env_auth.Authenticator'>, {}), ssl auth class=('env', <class 'xpra.server.auth.env_auth.Authenticator'>, {}), vsock auth class=None

...

2016-08-16 17:47:09,638 socktype=tcp, auth class=('env', <class 'xpra.server.auth.env_auth.Authenticator'>, {}), encryption=, keyfile=
2016-08-16 17:47:09,640 creating authenticator ('env', <class 'xpra.server.auth.env_auth.Authenticator'>, {})
2016-08-16 17:47:09,645 env=env
2016-08-16 17:47:09,646 processing authentication with env, response=None, client_salt=, challenge_sent=False
2016-08-16 17:47:09,646 challenge: ('935fa12933e146c3aebe195577eddc66669a2272e2d94267b9227c2cbe0c542f', 'hmac')
2016-08-16 17:47:09,647 Authentication required by env authenticator module
2016-08-16 17:47:09,647  sending challenge for 'hassenpfeffer' using hmac digest
2016-08-16 17:47:09,677 processing authentication with env, response=495f266ca8330619a476c0ed690349a6, client_salt=65303039376635323134666134383232626130666537363261316536373233346261363033386638646164623438653161313132356237393232623866363430, challenge_sent=True
2016-08-16 17:47:09,678 authenticate(495f266ca8330619a476c0ed690349a6) password=bob, hex(salt)=5c03055f5657070b02070350000e510103045203540e0307560600525351050254570f51010a510a0153005b000a5306030803000201055a5057525b53020656, hash=4e66dcc9043517be6d72a5df9128d00b
2016-08-16 17:47:09,678 expected '4e66dcc9043517be6d72a5df9128d00b' but got '495f266ca8330619a476c0ed690349a6'
2016-08-16 17:47:09,678 Error: hmac password challenge for 'hassenpfeffer' does not match
2016-08-16 17:47:09,679 Error: authentication failed
2016-08-16 17:47:09,679  invalid challenge response

I get the same output and failure when I try with an alternate env:

 TEST_PASSWORD=bob xpra --no-daemon --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --tcp-auth=env:name=TEST_PASSWORD -d auth

Tried again with the --auth=env:name=TEST_PASSWORD syntax listed above (leaving off the "tcp") with the same results again:

 TEST_PASSWORD=bob xpra --no-daemon --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --auth=env:name=TEST_PASSWORD -d auth

Tried again with the password on the command line, and failed:

xpra --no-daemon --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --auth=password:value=bob -d auth

Tried again with password on the command line and without the "no-daemon", failed again:

xpra --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --auth=password:value=bob -d auth

... and in this case I couldn't successfully pass a password to the xpra stop :13 command, so I had to use a kill -9 to stop the server.

Tried again with the syntax above and without the --no-daemon option (hoping the "./" for the password file would work with that syntax):

xpra --bind-tcp=0.0.0.0:1203 --start-child=xterm --mdns=no start :13 --start-new-commands=yes --tcp-auth=file:filename=./tcp-password.txt -d auth

Failed again with the additional file missing message in the log:

2016-08-16 18:07:34,806 Error: password file '/tcp-password.txt' is missing
2016-08-16 18:07:34,806 Error: password file authentication failed
2016-08-16 18:07:34,806  no password defined for 'hassenpfeffer'
2016-08-16 18:07:34,806 Error: authentication failed
2016-08-16 18:07:34,806  invalid challenge response

At this point I'm either missing something fairly obvious, or it's not working as expected when trying to connect a windows client to a fedora 23 vm server.

[Antoine Martin]

• password files are treated as binary files, so just copy them over to ensure that they are identical, or remove all tricky characters from it (especially newlines)
• Error: password file '/tcp-password.txt' is missing - same problem you had recently on another ticket: if you daemonize, the path is changed to "/" - either use an absolute path (ie: --tcp-auth=file:filename=`pwd`/tcp-password.txt) or don't daemonize

[alas]

Sure enough, the password files apparently didn't match. Even when I opened each in editors (nano on fedora server, programmer's notepad on windows client) to try to make them match, I was still failing.

Dropping the password file from the client onto the server though, authentication works with the --tcp-auth=file:filename=[full path], the env, and the --auth=password:value=my-password syntax.

I will note that, with the latter two methods of setting the server tcp-auth, I got a warning (which didn't affect success of authentication) from the server: Warning: printing conflicts with socket authentication module 'env' ... and sure enough, when I found a lawn gnome, the print dialog is not showing any of my configured printers, only a generic "xpra" printer, which is paused.

Testing to be sure, the first of the three authentication methods (--tcp-auth=file:filename=my-path-to-a-password) does allow for printing.

I got some logs... but upon further consideration, I will break this issue out to another ticket... and close this one.

[Denis01]

Hello.
xpra version - 2.0.1-1.r15491.el7_3
Problem with hmac - authentication failed

Multifile content:

u|p|1000|1000|:100
u1|s|1000|1000|tcp:127.0.0.1:10000

Log file:

12:32:35,044 parsed auth data from file /root/multifile.txt: {'u1': ('s', 1000, 1000, ['tcp:127.0.0.1:10000'], {}, {}), 'u': ('        p', 1000, 1000, [':100'], {}, {})}
12:32:35,044 authenticate: auth-info(u)=('p', 1000, 1000, [':100'], {}, {})
12:32:35,044 multifile authenticate_hmac(") password='p', hex(salt)=52010706540900041e0a5653571c570600071d055b06561e025c5002595        004025a5409555259520552505654195f0655041f005b025d1500005e561550000252, hash=3dd1f27e3600580723566423262a3029
12:32:35,045 expected '3dd1f27e3600580723566423262a3029' but got '"'
12:32:35,045 '''Error: hmac password challenge for 'u' does not match'''
12:32:35,045 '''Error: authentication failed'''
12:32:35,045 invalid challenge response

And there are some errors during the installation of this new version. Probable that's a reason.

Transaction check error:

file /usr/share/xpra/www/connect.html from install of xpra-common-2.0.1-1.r15491.el7_3.noarch conflicts with file from package xpra-html5-2.0-1.el7_3.noarch
file /usr/share/xpra/www/css/client.css from install of xpra-common-2.0.1-1.r15491.el7_3.noarch conflicts with file from package xpra-html5-2.0-1.el7_3.noarch
file /usr/share/xpra/www/index.html from install of xpra-common-2.0.1-1.r15491.el7_3.noarch conflicts with file from package xpra-html5-2.0-1.el7_3.noarch
file /usr/share/xpra/www/js/Client.js from install of xpra-common-2.0.1-1.r15491.el7_3.noarch conflicts with file from package xpra-html5-2.0-1.el7_3.noarch
file /usr/share/xpra/www/js/Utilities.js from install of xpra-common-2.0.1-1.r15491.el7_3.noarch conflicts with file from package xpra-html5-2.0-1.el7_3.noarch

[Antoine Martin]

@Denis01: it's impossible to reproduce your problems if you don't include the command lines you've used.
As for your transaction error, again - please include the full command line and output. This does not belong in this ticket though.

[Denis01]

Commands:

xpra start --start-child=/bin/gedit --bind-tcp=0.0.0.0:10000 :100 -d auth
xpra proxy :13 --bind-tcp=0.0.0.0:10002 --tcp-auth=multifile:filename=/root/multifile.txt -d auth

[Antoine Martin]

@Denis01: you must be connecting from somewhere to trigger authentication...

[Denis01]

ops.
HTML client.
And by the way browser sees the logon page with --html=on or without --html in the command start.
Tried both - the same auth problem.

[Antoine Martin]

HTML client

Likely a problem with the HTML client, which is fixed in 2.0.1.
Have you tried with a regular client?

And by the way browser sees the logon page with --html=on or without --html in the command start.

The default is "auto", which is the same as "on" if the html5 client code is installed.

[Antoine Martin]

Not heard back, closing.