#1159 closed enhancement (needinfo)
authentication modules refactoring
Reported by: | Antoine Martin | Owned by: | Denis01 |
---|---|---|---|
Priority: | critical | Milestone: | 0.17 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
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)
Change History (14)
comment:1 Changed 6 years ago by
Owner: | changed from Antoine Martin to alas |
---|
comment:2 Changed 6 years ago by
Priority: | major → critical |
---|
comment:3 Changed 6 years ago by
Owner: | changed from alas to Antoine Martin |
---|
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.
comment:4 Changed 6 years ago by
Owner: | changed from Antoine Martin to alas |
---|
- 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
comment:5 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:6 Changed 5 years ago by
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
comment:7 Changed 5 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:8 Changed 5 years ago by
Owner: | changed from alas to Denis01 |
---|---|
Status: | reopened → new |
@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.
comment:9 Changed 5 years ago by
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
comment:10 Changed 5 years ago by
@Denis01: you must be connecting from somewhere to trigger authentication...
comment:11 Changed 5 years ago by
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.
comment:12 Changed 5 years ago by
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.
comment:13 Changed 5 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
Not heard back, closing.
comment:14 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1159
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 toXPRA_PASSWORD
), ie:XPRA_PASSWORD=mysecret xpra start --auth=env
orSOME_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 haveauth
,tcp-auth
andvsock-auth
but only onepassword-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:
Notes:
bind=/path/to/sockdir
because the default config has one already, but I think it makes this example clearer showing them all as pairsauth=none
or whatever for any of those auth options, as beforetcp-auth=auth
if no module is specified for tcp, this is to ease the transition from older versions which did not havetcp-auth
at allThings this may break / cause problems with: