Setup XPRA for always-on access

[stdedos]

I'm trying to finally get rid of Teamviewer and use xpra (especially with the via-browser stack).

As traditionally, I don't have it installed - so, therefore, I don't have the service 😕

I tried:

> xpra\Xpra-x86_64_6.0-r35043\Xpra-Proxy_cmd.exe
2024-02-23 00:03:58,918 created tcp socket '0.0.0.0:14500'
2024-02-23 00:03:58,923 Warning: missing dbus module
2024-02-23 00:03:58,923  for Python 3.11.7 (main, Dec  7 2023, 09:07:50)  [GCC 13.2.0 64 bit (AMD64)]
2024-02-23 00:03:58,978 wrote pid 25484 to 'C:\Users\stdedos\AppData\Roaming\Xpra\sessions\1000\server.pid'
2024-02-23 00:03:58,993 created named pipe 'Xpra\xpra-service'
2024-02-23 00:03:59,006 Warning: failed to load the mdns publishers
2024-02-23 00:03:59,006  dynamic module does not define module export function (PyInit_zeroconf)
2024-02-23 00:03:59,006  No module named 'avahi'
2024-02-23 00:03:59,006  install 'python-avahi', 'python-zeroconf'
2024-02-23 00:03:59,006  or use the 'mdns=no' option
2024-02-23 00:03:59,057 Warning: cannot access directory 'C:\ProgramData\Microsoft\Windows\Start Menu\Προγράμματα':
2024-02-23 00:03:59,058  [WinError 5] Δεν επιτρέπεται η πρόσβαση: 'C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Προγράμματα'
2024-02-23 00:03:59,076 xpra is ready.
2024-02-23 00:03:59,077 xpra proxy server version 6.0-r35043 (g48292788a) beta
2024-02-23 00:03:59,077  running with pid 25484 on Microsoft Windows
2024-02-23 00:03:59,077  cpython 3.11
2024-02-23 00:03:59,180 Warning: cannot access directory 'C:\Users\stdedos\AppData\Roaming\Microsoft\Windows\Start Menu\Προγράμματα':
2024-02-23 00:03:59,181  [WinError 5] Δεν επιτρέπεται η πρόσβαση: 'C:\\Users\\stdedos\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Προγράμματα'

... it'd be nice if it could announce itself (and that somehow be picked up and shown by other xpra's running on the same network).

However, my most important issue is that I don't know how to authenticate to it.
Is it my Windows credentials? It doesn't work

Also, since it's not possible to use SSH keys (... I guess), then I'd like to also "do something about" encryption.

Is there any documentation for it?

I see https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Service.md, but looks like Linux

[totaam]

... it'd be nice if it could announce itself (and that somehow be picked up and shown by other xpra's running on the same network).

The problem comes from:

Warning: failed to load the mdns publishers
dynamic module does not define module export function (PyInit_zeroconf)

I am not seeing this problem with current builds.

However, my most important issue is that I don't know how to authenticate to it.

Your windows credentials should work.
But, I'm not sure why you're running a proxy. (it needs work on MS Windows to do what we want it to do - which is to support multiple concurrent users with individual graphical sessions - near impossible with most editions of MS Windows, for licensing reasons mostly)
Just run a regular shadow server, it won't cost any CPU until you actually connect to it.
And you don't need to use the command line to start it as there's a menu entry for that in your start menu.
You can even easily set it to auto-start on login.

[stdedos]

Your windows credentials should work.

Am I doing it right?

xpra\Xpra-x86_64_6.0-r35620>Xpra_cmd.exe shadow --bind-ws=0.0.0.0:10000,auth=win32 --no-audio
...
2024-07-06 11:17:10,820 Authentication required by win32 authenticator module
2024-07-06 11:17:10,820  sending challenge using 'xor' digest over ws connection
2024-07-06 11:17:21,318 Error: win32 authentication check failed:
2024-07-06 11:17:21,319  argument 3: TypeError: wrong type
2024-07-06 11:17:21,319 Warning: authentication failed
2024-07-06 11:17:21,319  authentication failed

The xpra shortcut does

xpra/packaging/MSWindows/xpra.iss

Line 48 in 5963153

Name: "{group}\Xpra Shadow Server"; Filename: "{app}\Xpra.exe"; WorkingDir: {app}; Parameters: "shadow --bind-tcp=0.0.0.0:14500,auth=sys,ssl-cert=auto"; IconFilename: {app}\icons\server-connected.ico

But how could it work?

xpra/packaging/MSWindows/xpra.iss

Lines 183 to 196 in 5963153

	begin
	Log('PostInstall()');
	cert := ExpandConstant('{commonappdata}\Xpra\ssl-cert.pem');
	if (NOT FileExists(cert)) then
	begin
	config := ExpandConstant('{app}\openssl.cfg');
	args := 'req -new -newkey rsa:4096 -days 365 -nodes -x509 -config "'+config+'" -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=localhost" -out "'+cert+'" -keyout "'+cert+'"';
	openssl := ExpandConstant('{app}\OpenSSL.exe');
	if (FileExists(openssl)) then
	begin
	Log('PostInstall() generating ssl-cert.pem');
	Exec(openssl, args, '', SW_HIDE, ewWaitUntilTerminated, ResultCode);
	end;
	end;

None of the files mentioned here exist 😕

---

... I switched to auth=sys, but it doesn't help.

Nor does admin/no-admin account help

[stdedos]

Also https://github.com/Xpra-org/xpra/blob/master/xpra/server/auth/win32.py does not exist on the "production artifacts". Idk if that was intended or not - but ofc I cannot verify where my issue lies

[stdedos]

xpra\Xpra-x86_64_6.0-r35620>Xpra_cmd.exe shadow --bind-ws=0.0.0.0:14500,auth=password:value=mysecret --no-audio means that the password here

is mysecret, right?

... because it's not working 😓

[totaam]

Sorry about that, the parsing had been refactored and I had forgotten to update the documentation to match: 39527ec

It works for me now, with both auth=password and auth=sys.
Tested with both the Python client and the html5 client.

[stdedos]

Split the shadow issue into #4287

[totaam]

argument 3: TypeError: wrong type

Fixed in ab9e79b

None of the files mentioned here exist 😕

I do see openssl.exe, but openssl.cfg seems to have gone AWOL, updated to use the correct source location in d23f941
That would explain why the certificate was not generated during PostInstall, but the fix above is not sufficient.
It still doesn't generate it... and debugging InnoSetup is no fun. (can't remember how to do it TBH)

... I switched to auth=sys, but it doesn't help.

sys is a generic alias for win32. (or pam on Posix)
I'm seeing this too - even on Linux which is weird, I'm on it.

[stdedos]

That would explain why the certificate was not generated during PostInstall, but the fix above is not sufficient.\nIt still doesn't generate it... and debugging InnoSetup is no fun. (can't remember how to do it TBH)

... may I suggest a Python/Bash script? 😅 with/without argparse
Although I do see the appeal of Innosetup, having a "custom" script means that the user can re-use it.
I see also that you are not doing "anything special".

... But, if maybe a dream idea come true, xpra can exchange ephemeral certificates to connect with clients (so eg xpra pre-auth + xpra client quic could be the xpra shadow ssh convenient equivalent...)

[totaam]

may I suggest a Python/Bash script?

I like the idea of moving ssl generation to a new subcommand: #4288

xpra can exchange ephemeral certificates to connect with clients (so eg xpra pre-auth + xpra client quic could be the xpra shadow ssh convenient equivalent...)

How would you exchange that certificate?

[stdedos]

Authenticating to the proxy somehow? With the "known methods"

(Technically, you could exchange them via the ws://, after auth?)

[totaam]

I don't understand what you're saying.
Client and server need to agree on the authenticity of the server-side certificate.
That's done via a CA, or by verifying the cert hash. Anything exchanged before that can be intercepted and is susceptible to MITM.

[stdedos]

Oh yeah right 🤦 Drew a blank there

[totaam]

This discussion is becoming a bit unwieldy, apart from solving the SSL setup (#3299) - is there anything that has not been addressed?

[stdedos]

No, I don't think so.

#4288 and #3299 should address the windows shadow issue