Making use of u2f

[sbradnick]

Describe the bug
I happened upon #1789 and would like to make use of the facility. I have a few Yubikeys; a blue one as well as, I believe, a v4NEO and v5NFC (I can never remember :P), but something like 3-5 total. I make use of the v4 for OTPs and the v5 along with GPG for encrypting,signing and ssh authentication. Nothing too fancy and I'm not claiming to have an overly deep understanding of the guts of Yubikeys or their functions, etc.

The error:

Exception in thread authenticate connection:
Traceback (most recent call last):
  File "/usr/lib64/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib64/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.10/site-packages/xpra/server/server_core.py", line 2038, in verify_auth
    if not authenticator.authenticate(c):
  File "/usr/lib64/python3.10/site-packages/xpra/server/auth/sys_auth_base.py", line 118, in authenticate
    r = self.do_authenticate(caps)
  File "/usr/lib64/python3.10/site-packages/xpra/server/auth/sys_auth_base.py", line 140, in do_authenticate
    return self.authenticate_check(challenge_response, client_salt)
  File "/usr/lib64/python3.10/site-packages/xpra/server/auth/u2f_auth.py", line 119, in authenticate_check
    verifier = public_key.verifier(sig, ec.ECDSA(hashes.SHA256()))
AttributeError: '_EllipticCurvePublicKey' object has no attribute 'verifier'

To Reproduce
Steps to reproduce the behavior:

1. server command: xpra start --start="xterm" --bind-tcp=0.0.0.0:10000 --tcp-auth=u2f -d auth
2. client command: xpra attach tcp://192.168.0.105:10000 -d auth
3. specific action to trigger the bug: All looks to go well and I'm prompted to touch the Yubikey, then I get the python error. I've also tried it locally (same server command, but 127.0.0.1 for the attach). I have ~/.config/xpra/u2f-pub.hex on the destination host and ~/.config/xpra/u2f-keyhandle.hex,u2f-pub.hex on the client where the Yubikey is plugged in. I ran python3 /usr/lib64/python3.10/site-packages/xpra/client/gtk_base/u2f_tool.py to accomplish that.

System Information (please complete the following information):

• Server OS: openSUSE Tumbleweed (20220714)
• Client OS: openSUSE Tumbleweed (20220714)
• Xpra Server Version [e.g. 4.2.3]: xpra-4.4+git20220621.872c7f8d8
• Xpra Client Version [e.g. 4.3]: xpra-4.4+git20220621.872c7f8d8
  About reports:

     4.4
Python 3.10, 64bit

revision 31329
commit g872c7f8d8 from master branch
with 335 local changes
2022-06-21 00:00

using Cython 0.29.30
gcc (SUSE Linux) 12.1.1 20220629 [revision 7811663964aa7e31c3939b859bbfa2e16919639f]

Additional context
I don't know if I'm missing some python modules, I started picking through the ones listed in the build section and I feel that I have most/all installed. I have the client/server logs and will attach them if this doesn't appear to be good ole fashioned 'user error'.

[totaam]

My guess at this point is that either pyu2f doesn't support EC keys or some changes to https://github.com/pyca/cryptography cause this incompatibility.
The bug fix commit above will just fail keys that can't be used rather than failing authentication completely.
I don't think that there's much more we can do about it from xpra's side.

You may be able to get around it by not using EC keys (EllipticCurvePublicKey does't have a verifier attribute).
https://github.com/google/pyu2f doesn't seem to be actively maintained but you may want to ask there.

[sbradnick]

Do you know how/where/why _EllipticCurvePublicKey is coming into play? Is it some choice I've made somewhere in a config (even outside of Xpra)? [sorry to drop a 'what's wrong w/ my individual config' question in your lap ;)] Possibly a build-time item I need to adjust?

I'm using a blue Yubikey (basically, my original one before the v4/v5 ones were purchased) which I could 'reset' if somehow I caused this "_EllipticCurvePublicKey" aspect to come into play with it. My 'daily driver' v5NFC key uses [ed|cv]25519 CSEA items, but I'm not using that one with Xpra.

I branched and built some updated versions of cryptography (37.0.4 [vs. 37.0.2]) and pyu2f (w/ the "latest" commits up to 20211122):

$ rpm -qa \*cryptography\* \*pyu2f\*
python310-cryptography-37.0.4-0.x86_64
python310-pyu2f-0.1.5a+git20211122.064be5a-0.noarch

But there's not a noticable change in client/server output.

Could it be a python310 issue?

Thanks for getting back to me :-)

[totaam]

This is beyond my expertise. A quick search can only find:
https://github.com/pyca/cryptography/blob/7da2dc33081d0ec53437b7676ec5ef8ac9977061/src/cryptography/hazmat/primitives/asymmetric/ec.py#L152-L161

Could it be a python310 issue?

Unlikely.
Best to ask one of those two projects though.

I am going to close this because I don't think there's much more we can do from xpra's side.
If you find more information or create an upstream ticket, please link back here.

[sbradnick]

I've opened an issue on pyca/cryptography. Thanks again :)

[totaam]

The commit above should fix it - please let me know if that works.

[sbradnick]

I haven't done a rebuild since [I believe] June 21st, looks like I've had to:

• add procps-devel as a "BuildRequires"
• remove /etc/pam.d[/xpra] from having a place in the file list for the RPM
• addition of /etc/xpra/content-parent/10_default.conf

Just want to be sure I'm not goofing something else up (for myself and other openSUSE users) chasing down using a Yubikey :P

That's what I've done at least, & I'd like to report that I was able to use the blue Yubikey to make a successful connection now :)

[sbradnick]

I am getting this happening, the tray menu not working; seems to be independent of Yubikeys/u2f, etc. I've tried via a standard ssh startup xpra start ssh://[email protected] --start=xterm and I get my xterm, but the tray menu doesn't seem to function.

2022-07-17 17:11:29,459 Error: failed to setup menu
2022-07-17 17:11:29,460  cannot import name 'get_qrencode_fn' from 'xpra.net.qrcode' (/usr/lib64/python3.10/site-packages/xpra/net/qrcode.py)

Server:

2022-07-17 17:01:24,580 client   1 @24.641 menu is not available yet
2022-07-17 17:01:29,807 client   1 @29.868 menu is not available yet
2022-07-17 17:01:30,517 client   1 @30.578 menu is not available yet

Client:

2022-07-17 17:01:02,796 menu is not available yet
2022-07-17 17:01:08,023 menu is not available yet
2022-07-17 17:01:08,733 menu is not available yet

[totaam]

Error: failed to setup menu

That was already fixed earlier in 78867e7

looks like I've had to:

Oops. I thought I had done a rebuild recently - but clearly not!
Sorry about that.

• procps-devel: 6e101f8
• addition of /etc/xpra/content-parent/10_default.conf dc824ff
• remove /etc/pam.d[/xpra] - bb4e616

That's for git master, but you could also run the latest stable version and patch the u2f authentication module there.

[sbradnick]

I'm tied to the reproducible builds scenario via OBS - which I like, if that sounds like a complaint :) - so I use those mechanisms to pull down the latest git (including <project dir>/.git, which isn't the norm for OBS (using osc) and it excludes it, but not a difficult thing to work around).

Was using 63e6b61 for what I'd posted last, when getting that problem.

Now using bb4e616 and the build reports:

[  410s] Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/abuild/rpmbuild/BUILDROOT/xpra-4.4+git20220717.bb4e61677-0.x86_64
[  410s] error: Installed (but unpackaged) file(s) found:
[  410s]    /etc/pam.d/xpra
[  410s] 
[  410s] 
[  410s] RPM build errors:
[  410s]     Installed (but unpackaged) file(s) found:
[  410s]    /etc/pam.d/xpra

So I added it back to the %files section.

As far as the menu aspect goes, getting the same "menu is not available yet".

[sbradnick]

Going back to 20220621's 872c7f8 then adjusting u2f_auth.py allows the Yubikey auth and the menu to both work. I'll go through some more of the commits after that particular one tommorrow and see if I can determine where it breaks ~ unless you think that's a waste of time :)

[totaam]

So I added it back to the %files section.

Correct, that's what bb4e616 fixed - sorry, it was not clear.

"menu is not available yet"
(..)
I'll go through some more of the commits after that particular one tommorrow and see if I can determine where it breaks

It could be f45ee56 which now blocks the threaded initialization waiting for numpy to load just once.
I haven't been able to test it properly as I don't have an nvidia card in my computer at the moment, do you?
(this could explain a delay - though it should eventually complete and send the menu to the client)

[sbradnick]

My work laptop has an Intel and Nvidia card in it, should be defaulting to Nvidia; at least glxinfo -B when directly logged into it leads me to believe that to be the case:

So I'm generally using this setup:

Client:

Device-1: Intel GeminiLake [UHD Graphics 600] driver: i915 v: kernel

Server:

Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] driver: i915 v: kernel
Device-2: NVIDIA TU117GLM [Quadro T1000 Mobile] driver: nvidia v: 515.57

[sbradnick]

It's starting to look like 4ef353a is the last commit the fully works for me. I start getting random build failures ( outside of new files coming in or others going away, standard fare there :) ).

I have a little list of hashes ~ some of which build, but need u2f_auth.py edit [reasonable :)] and others which have build issues and they fail.

LAST GOOD
4ef353a

NON-WORKING menu
ff53b3f
9b4e742
6f814e0
0f05bfd
67f8213
5724ed4

BUILD FAILS
4646453
df39306
f6844ed
de76ccd
c58a36d
718201f
4cd838a

KNOWN GOOD
872c7f8
9fd8b66
5fa0e6d
d3eb570
f6f349a
c37a970

[totaam]

Ignoring the build failures for now (sorry, working on MS Windows builds and refactoring - breakage was inevitable - should be finished soon), can you try reverting f45ee56 ?
The commits immediately after 4ef353a are:

• 4646453 - so as of 6b84ef9 you can now run with XPRA_GUESS_CONTENT=0 to disable this updated module (perhaps there's a bug in there - a loop or something? Is your CPU busy?)
• df39306 - can't be that: unless you specify it, it won't be loaded
  Then after that is a lot of refactoring..

[sbradnick]

Ignoring the build failures for now (sorry, working on MS Windows builds and refactoring - breakage was inevitable - should be finished soon), can you try reverting f45ee56 ?

Unless I'm not comprehending your suggestion in the quote (very possible!), if I use a build of ff53b3f (which is the commit right before f45ee56) the menu doesn't work.

I also built 6b84ef9 and ... everything works fine ;)

2022-07-18 18:45:19,784 activate your U2F device for authentication and I get a working menu.

[totaam]

I meant reverting that commit on top of git head to see if that was the problem, but since everything is working again then it wasn't this one anyway - some other commit, we may never know which one.