authentication connection lost

[totaam]

Issue migrated from trac ticket # 1709

component: core | priority: major | resolution: invalid | keywords: authentification

2017-11-27 01:47:59: Boruch created the issue

---

version: Xpra gtk2 client version 2.1.3-r17247 64-bit
platform: Linux 4.9.0-4-amd64 x86_64 Debian

I'm not sure if I'm using the authentication feature correctly, but here's one scenario of recent trouble:

xpra start --bind=auto --auth=pam --start=xfce4-terminal

So far, seems so good ...

xpra attach :1

No opportunity to enter a password, but reasonably quickly the following error messages appeared

2017-11-26 20:07:57,294 Error: authentication failed:
2017-11-26 20:07:57,295  this server requires authentication, please provide a password
2017-11-26 20:07:57,338 Connection lost

The tail of the log file offered some more detail:

Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
2017-11-26 20:15:44,686 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
2017-11-26 20:15:44,789 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
[33m2017-11-26 20:15:45,171 Warning: unused keyword arguments for PAM authentication:[0m
[33m2017-11-26 20:15:45,172  {'exec_cwd': '/home/me', 'connection': unix-domain socket:/home/me/.xpra/E15-2016-1, 'name': 'me'}[0m
2017-11-26 20:15:45,172 Authentication required by PAM authenticator module[0m
2017-11-26 20:15:45,172  sending challenge for username 'me' using xor digest[0m
2017-11-26 20:15:47,548 client has requested disconnection: no password available[0m
2017-11-26 20:15:47,548 Disconnecting client /home/me/.xpra/E15-2016-1:[0m
2017-11-26 20:15:47,549  client request[0m

2017-11-26 20:15:55,312 got signal SIGTERM, exiting[0m
2017-11-26 20:15:55,334 killing xvfb with pid 11355[0m
2017-11-26 20:15:55,334 removing socket /home/me/.xpra/E15-2016-1[0m
Terminated
(II) Server terminated successfully (0). Closing log file.

I then tried an alternative:

xpra start --bind=auto --auth=password:value=me --start=xfce4-terminal
xpra attach :2 --auth=password:value=me

with the same output to STDERR...

2017-11-26 20:39:44,134 Error: authentication failed:
2017-11-26 20:39:44,134  this server requires authentication, please provide a password
2017-11-26 20:39:44,169 Connection lost

And this to the log...

Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
2017-11-26 20:39:41,250 New unix-domain connection received on /home/me/.xpra/E15-2016-2[0m
2017-11-26 20:39:41,353 New unix-domain connection received on /home/me/.xpra/E15-2016-2[0m
2017-11-26 20:39:42,023 Authentication required by password authenticator module[0m
2017-11-26 20:39:42,023  sending challenge for username 'me' using hmac+sha512 digest[0m
2017-11-26 20:39:44,136 client has requested disconnection: no password available[0m
2017-11-26 20:39:44,136 Disconnecting client /home/me/.xpra/E15-2016-2:[0m
2017-11-26 20:39:44,136  client request[0m

A third very different scenario that I tried had a very different failure, so I'll post it in another ticket.

[totaam]

2017-11-27 03:32:26: antoine commented

---

Warning: unused keyword arguments for PAM authentication:
 {'exec_cwd': '/home/me', 'connection': unix-domain socket:/home/me/.xpra/E15-2016-1, 'name': 'me'}

The message will be slightly improved with r17522.
The pam module does not take any extra configuration options.

xpra attach :2 --auth=password:value=me

auth does not make sense for attach, the username and passwords are meant to be specified using the connection URI. ie: xpra attach tcp://username:password@host:port/

---

Anyway, this works fine here.
The code checks if a password is available, and if not then it uses getpass to prompt for the password, it looks like this:

Please enter the password for unix-domain server /run/user/1000/xpra/desktop-5 :

The only reasons why it would not display the prompt are:

• you have already supplied the password (ie: in the URI) - not the case here
• stdin is not a tty or it is a buggy shell (ie: from an MSYS shell, which doesn't work)

Please post the full client log with "-d auth".

Running this code should also be pretty much equivalent to what the client will be doing:

python -c 'import sys;print("isatty=%s" % sys.stdin.isatty());import getpass;getpass.getpass("password-prompt:")'

[totaam]

2017-11-27 03:32:36: antoine changed owner from antoine to Boruch

[totaam]

2017-11-27 23:02:28: Boruch uploaded file :1.log (45.4 KiB)

[totaam]

2017-11-27 23:03:43: Boruch commented

---

auth does not make sense for attach, the username and passwords are meant to be specified using the connection URI. ie: xpra attach tcp://username:password@host:port/

That may be part of my confusion / uncertainty of how to use the feature. How should a password be used for a local unix socket connection, which I understand to be option --bind=auto (is that correct?).

I'm attaching your requested log, with option --debug=auth for the xpra client of the following session:

$ xpra start --bind=auto --auth=pam --start=xfce4-terminal
Warning: cannot use the system proxy for 'start' subcommand,
 failed to connect to '/run/xpra/system':
 [Errno 2] No such file or directory
Entering daemon mode; any further errors will be reported to:
  /home/me/.xpra/S25051.log
Actual display used: :1
Actual log file name is now: /home/me/.xpra/:1.log

$xpra attach -d auth :1
2017-11-27 17:41:11,202 Xpra gtk2 client version 2.1.3-[r17247](../commit/d000900a3e413ee659c5957f2604514103ccfc01) 64-bit
2017-11-27 17:41:11,203  running on Linux Devuan 1.0 jessie
2017-11-27 17:41:18,295 GStreamer version 1.10.4 for Python 2.7.13 64-bit
2017-11-27 17:41:21,183 Warning: vendor 'Intel Open Source Technology Center' is greylisted,
2017-11-27 17:41:21,183  you may want to turn off OpenGL if you encounter bugs
2017-11-27 17:41:21,296 PyOpenGL warning: missing accelerate module
2017-11-27 17:41:21,459 OpenGL enabled with Mesa DRI Intel(R) Bay Trail
2017-11-27 17:41:21,724  keyboard settings: rules=evdev, model=pc104, layout=us,il
2017-11-27 17:41:21,728  desktop size is 1366x768 with 1 screen:
2017-11-27 17:41:21,728   :0.0 (361x203 mm - DPI: 96x96)
2017-11-27 17:41:21,729     eDP1 (344x193 mm - DPI: 100x101)
2017-11-27 17:41:22,480 keyboard layouts: us,il,us,il
2017-11-27 17:41:24,728 processing challenge: ['415233c3d9a54fbc85595be70f7fbc6b8166958d708e4a0aa581b8959b19efcb', '', 'xor', 'hmac+sha512']
2017-11-27 17:41:24,728 Error: authentication failed:
2017-11-27 17:41:24,729  this server requires authentication, please provide a password
2017-11-27 17:41:24,730 Connection lost

[totaam]

2017-11-27 23:57:11: Boruch commented

---

Not sure if this extra data point is useful, but when repeatedly trying xpra stop, the response is:

Error: authentication failed:
 this server requires authentication, please provide a password

and the addition to the log file is:

2017-11-27 18:50:23,543 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
[36m2017-11-27 18:50:23,545 socktype=unix-domain, auth class=('pam', <class 'xpra.server.auth.pam_auth.Authenticator'>, {'exec_cwd': '/home/me'}), encryption=, keyfile=[0m
2017-11-27 18:50:23,652 New unix-domain connection received on /home/me/.xpra/E15-2016-1[0m
[36m2017-11-27 18:50:23,654 socktype=unix-domain, auth class=('pam', <class 'xpra.server.auth.pam_auth.Authenticator'>, {'exec_cwd': '/home/me'}), encryption=, keyfile=[0m
[36m2017-11-27 18:50:25,058 creating authenticator ('pam', <class 'xpra.server.auth.pam_auth.Authenticator'>, {'exec_cwd': '/home/me'}) with username=me[0m
[36m2017-11-27 18:50:25,059 authenticator: pam(me, {'exec_cwd': '/home/me', 'connection': unix-domain socket:/home/me/.xpra/E15-2016-1})=PAM[0m
[36m2017-11-27 18:50:25,059 processing authentication with PAM, response=None, client_salt=, challenge_sent=False, digest_modes=['hmac', 'xor', 'hmac+whirlpool', 'hmac+sha512', 'hmac+sha384', 'hmac+sha256', 'hmac+sha224', 'hmac+sha1', 'hmac+ripemd160', 'hmac+md5-sha1', 'hmac+md5', 'hmac+md4', 'hmac+blake2s256', 'hmac+blake2b512', 'hmac+SHA512', 'hmac+SHA384', 'hmac+SHA256', 'hmac+SHA224', 'hmac+SHA1', 'hmac+RIPEMD160', 'hmac+MD5-SHA1', 'hmac+MD5', 'hmac+MD4', 'hmac+BLAKE2s256', 'hmac+BLAKE2b512'], salt_digest_modes=['hmac+whirlpool', 'hmac+sha512', 'hmac+sha384', 'hmac+sha256', 'hmac+sha224', 'hmac+sha1', 'hmac+ripemd160', 'hmac+md5-sha1', 'hmac+md5', 'hmac+md4', 'hmac+blake2s256', 'hmac+blake2b512', 'hmac+SHA512', 'hmac+SHA384', 'hmac+SHA256', 'hmac+SHA224', 'hmac+SHA1', 'hmac+RIPEMD160', 'hmac+MD5-SHA1', 'hmac+MD5', 'hmac+MD4', 'hmac+BLAKE2s256', 'hmac+BLAKE2b512'][0m
[36m2017-11-27 18:50:25,060 get_challenge(['hmac', 'xor', 'hmac+whirlpool', 'hmac+sha512', 'hmac+sha384', 'hmac+sha256', 'hmac+sha224', 'hmac+sha1', 'hmac+ripemd160', 'hmac+md5-sha1', 'hmac+md5', 'hmac+md4', 'hmac+blake2s256', 'hmac+blake2b512', 'hmac+SHA512', 'hmac+SHA384', 'hmac+SHA256', 'hmac+SHA224', 'hmac+SHA1', 'hmac+RIPEMD160', 'hmac+MD5-SHA1', 'hmac+MD5', 'hmac+MD4', 'hmac+BLAKE2s256', 'hmac+BLAKE2b512'])= 38303661663336373736613634373662623964356632626634636138666461666463326534653031653432663430646138643037343036326235636166363538, xor[0m
2017-11-27 18:50:25,060 Authentication required by PAM authenticator module[0m
2017-11-27 18:50:25,060  sending challenge for username 'me' using xor digest[0m
2017-11-27 18:50:25,069 client has requested disconnection: no password available[0m
2017-11-27 18:50:25,070 Disconnecting client /home/me/.xpra/E15-2016-1:[0m
2017-11-27 18:50:25,070  client request[0m

I can stop the xpra session using pkill, but does xpra have a way of gracefully handling this?

[totaam]

2017-11-28 03:27:34: antoine commented

---

How should a password be used for a local unix socket connection, which I understand to be option --bind=auto (is that correct?).
bind=auto is the default so unix sockets will always be created unless you specify bind=none (and I'm not sure why you would want to do that, but it's there..)

The format is the same as for other protocols, though you may need r17533 or later for the 2.2 branch:

xpra attach socket://username:password@/the/socket/path

This cannot be used with the simpler form of xpra attach :DISPLAY.
Note: when using "pam" auth module, the user can specify any user account on the system, not just the user account of the owner of that socket. This may be a security issue depending on how you deploy things. This module is primarily meant to be used with the ProxyServer.

Not sure if this extra data point is useful, but when repeatedly trying xpra stop, the response is:
You have configured authentication for your sockets, so all the commands using those sockets will need to provide the credentials, including "xpra stop".

I can stop the xpra session using pkill, but does xpra have a way of gracefully handling this?
xpra should handle pkill, but the correct way is via "xpra stop".
Either don't use authentication on your unix domain sockets (or use "peercred" auth module), or provide the password.

As per comment:1, please post:

• the client "-d auth" log
• try the sample python getpass command example

[totaam]

2017-11-28 03:57:36: Boruch commented

---

The log that I uploaded ~five hours ago was the wrong one?

[totaam]

2017-11-28 04:16:52: antoine commented

---

The log that I uploaded ~five hours ago was the wrong one?
Sorry, my bad, missed the client log from comment:3.
Please try again with r17535 or later, which includes more debug logging.

The sample getpass output is not there AFAICT, try running this:

python -c 'import sys;print("isatty=%s" % sys.stdin.isatty());import getpass;getpass.getpass("password-prompt:")'

[totaam]

2017-11-28 04:32:39: Boruch commented

---

Please try again with r17535 or later, which includes more debug logging.

My package manager is pulling packages directly from the winswitch.org repository, and shows r17247 as the latest-and-greatest . . .

[totaam]

2017-11-28 04:35:34: antoine commented

---

My package manager is pulling packages directly from the winswitch.org repository, and shows r17247 as the latest-and-greatest . . .
That's pretty old (for beta builds), which exact distribution is this?

[totaam]

2017-11-28 05:19:07: Boruch commented

---

That's pretty old (for beta builds), which exact distribution is this?

I'm pulling in everything from here:

$ cat /etc/apt/sources.list.d/winswitch.list
deb http://winswitch.org/ stretch main

Debian has a command to list ALL versions of a package in a repository. For most repositories that means only candidate. winswitch lists ~65 (!) from ~0.14.10.

[totaam]

2017-11-28 05:20:46: Boruch commented

---

The python one-liner you asked me to test succeeds in issuing a text prompt for a password on the xterm on which it was executed.

[totaam]

2017-11-28 08:05:17: antoine commented

---

deb http://winswitch.org/ stretch main
Ah, right.
You should be using the beta repo:

deb http://winswitch.org/beta stretch main

as per Download.

The 2.2 beta version you have installed got posted to stable by mistake a while back and you were one of the unlucky ones who got it.. and we can't take it back.

For most repositories that means only candidate. winswitch lists ~65 (!) from ~0.14.10.
That's right. It is our policy to keep all versions available so people can easily downgrade or bisect.

[totaam]

2017-12-12 11:51:43: Boruch commented

---

For the past week I've been having what hopefully is an unrelated mini-disaster with X11, but since it might be related to my fiddling with xpra bleeding edge (I know, on my own responsibility), at this point, after exhausting all other ideas, I'll ask:

The bad news is that my X11 server no longer serves, issuing in most cases an error to ~/.local/share/xorg/Xorg.0.log: "modeset(0): drmSetMaster failed: Permission denied".

The good news is that this has been a unexpected opportunity to test xpra over ssh, and it works fine for me so far, although scrolling in firefox badly blurs text (debian-derivative MX-linux, xpra version0.14.10).

I've tried myriad of things, so at this point, I thought to ask whether anything in a typical playing with xpra or its configs or its interplay with X11 would contribute to such a thing?

The machine is a non-systemd version of debian (devuan) which has historically been very stable, until a week ago.

[totaam]

2017-12-12 12:15:44: antoine commented

---

... anything in a typical playing with xpra or its configs or its interplay with X11 would contribute to such a thing?
No. Xpra does not interfere in any way with the way Xorg is setup, not on Debian or any other distro.
The only package we may override in some cases is the [/wiki/Xdummy dummy driver], but this is not used by regular X11 sessions and we definitely have nothing to do with drm or permissions.

scrolling in firefox badly blurs...
This is much improved in later versions: #1426, #1232

xpra version 0.14.10
That version is full of critical security holes: Packaging DistributionPackages. Do not use.

[totaam]

2017-12-13 04:10:59: Boruch commented

---

xpra version 0.14.10

That version is full of critical security holes: Packaging DistributionPackages. Do not use.

Thanks. There'll be some dependency issues to address, but I'll take care of it.

[totaam]

2017-12-13 14:12:50: Boruch commented

---

Using xpra X11 version 2.3-r17613 64-bit, this ticket no longer is an issue, I think.

$xpra stop :3
Warning: invalid option: 'shadow-fullscreen'
Please enter the password for unix-domain server /home/me/.xpra/E15-2016-3 :
server requested disconnect:
 server shutdown
xpra at :3 has exited.

However, at least one other issue has replaced it, so I'll open another ticket. Thanks for the patience and support on this.

[totaam]

2017-12-13 14:13:14: Boruch changed status from new to closed

[totaam]

2017-12-13 14:13:14: Boruch set resolution to invalid