This is a tracker ticket for some changes already committed to trunk. Related to #983, #1133 and #1150. See also #888.
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:
bind=/path/to/sockdir
because the default config has one already, but I think it makes this example clearer showing them all as pairs
auth=none
or whatever for any of those auth options, as before
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
Things this may break / cause problems with:
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.
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
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.
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
@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.
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
@Denis01: you must be connecting from somewhere to trigger authentication...
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.
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.
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1159