xpra-html5
xpra-html5 copied to clipboard
Xpra-org
Separate authentication challenge support
From https://github.com/Xpra-org/xpra-html5/issues/95#issuecomment-918174444 we need a few things:
- retrying authentication - perhaps the xpra server could re-send the authentication challenge after some delay? Would we need to differentiate when authentication fails and when we just hit the next module in the server authentication list? Otherwise, the html5 client could re-connect but the user experience would not be as smooth.
- supporting multiple authentication challenges: this should already work via the new prompt (#96) but this will not work from the connect dialog as the client will just try to re-use the same password (should be easy to fix?) - we may also want to differentiate the proxy from the real backend server in the UI prompt?
- pass-through authentication, so the proxy establishes the connection to the backend server unauthenticated and leaves it to the client to authenticate (this needs an xpra proxy ticket - no changes in the html5 client should be needed here?)
- bonus: add generic authentication modules hooks for U2F, kerberos, OTP, whatever
Would we need to differentiate when authentication fails and when we just hit the next module in the server authentication list?
I think we can follow OpenSSH workflow here
we may also want to differentiate the proxy from the real backend server in the UI prompt?
Exactly. Just mention "proxy" and "backend" server to differentiate. I guess double-proxy is not going to happen :)
I think we can follow OpenSSH workflow here
Which is?
Just mention "proxy" and "backend" server to differentiate
"Just". The packets don't have a source marker. This would need to be added to the xpra protocol.
Which is?
Server: Authentication methods supported: publickey, password, gssapi Client: Attempting to use password … Server: Authentication methods supported: publickey, gssapi
ssh -vvv
Also, when we support more authenticatiin factors, I guess there will be no place for username/password in connect.html…
Even now specifying password in connect.html does not prevent password pop-up from appearing. We need to centralize the UX.
Which is?
Server: ...
No, I meant: how does it handle retries. We can't do the same as ssh and offer options, that's just not how the authentication modules are designed on the server: it's a sequential list of constraints.
Even now specifying password in connect.html does not prevent password pop-up from appearing.
That was a bug: efad629718a15155736a3ae95a02e6ca0ed43a30
No, I meant: how does it handle retries.
From what I see in ssh -vvv output, the server first announces a list of authenticators (constraints) and when client sends a password which is rejected, the server returns the list of authenticators still left (and password is among them for the number of retries), then after all retries are incorrect, the server announces the authenticator list with password excluded:
~ $ ssh -vvv [email protected]
OpenSSH_8.7p1, OpenSSL 1.1.1l 24 Aug 2021
...
# Here we get list of authenticators available
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: Vasyl Gello <[email protected]> (xxxx) RSA SHA256:/xxx agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_rsa
...
debug2: we did not send a packet, disable method
# Publickey auth round failed, proceed with password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
# 1st attempt
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
# 2nd attempt
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
# 3rd attempt
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey,password).
So I dont understand how sequential list of constraints in Xpra server differs from sequential list of constraibts in industry-standard OpenSSH :)
The packets don't have a source marker. This would need to be added to the xpra protocol.
Why not use display number for it? Proxy can occupy :14500 or even "-1" to indicate it is a proxy. The rest… To be honest, UX-wise I would prefer the list of available displays to attach with some info about them after I have authenticated on proxy. Not before I authenticated (remember our old conversation?), but after :)
Like I said here https://github.com/Xpra-org/xpra-html5/issues/97#issuecomment-918797171: We can't do the same as ssh and offer options, that's just not how the authentication modules are designed on the server: it's a sequential list of constraints. There are no retries at present. You either pass the challenge or you get booted out on the spot. Adding retries should be possible but I'm not going to change the whole authentication mechanism to allow the client to choose which authentication method to try.
Why not use display number for it?
Because the authentication packets have no data to identify the source, and therefore no display number.
Tgen differentiation of servers is not needed. We can state in documentation that every server (be it proxy or backend) supports one authentication attempt of given type. Did I understand your point correctly?
.. supports one authentication attempt of given type
Currently that's true. But adding retries can be done. It's just that it wouldn't be obvious to the user if the new password prompt is just a retry or another authentication module, unless the protocol is also enhanced to allow the client to differentiate them.
i think if we are going to add u2f etc, we need to differentiate the cases & clients. But I understand your concerns on breaking the backward compatibility
With the commit above, this is a step in the right direction:
echo -n foo > password0.txt
echo -n bar > password1.txt
xpra start --start=xterm \
--bind-tcp=0.0.0.0:10000,auth=file:filename=password0.txt,auth=file:filename=password1.txt
I can connect with:
xdg-open "http://localhost:10000/?password0=foo&password1=bar"
Both challenges are processed by the same server, but forwarding authentication challenges through the proxy server should be doable too.
Great! I managed to get into Xpra server on the same machine started like xpra start --start-child=xeyes --exit-with-children --auth password:value=xpra via HTML5 client without the need to specify passwordN options on URL! The password was asked smoothly!
From Xpra manpage I conclude that username is relevant only for sys authentication so in theory it should not be a problem. Be it a problem, we can always instruct HTML5 client to ask username too when server auth is sys.
Great! I managed to get into Xpra server on the same machine started like...
Your command line doesn't have any tcp sockets so it's not clear to me how you managed to connect an HTML5 client to it.
From Xpra manpage I conclude that username is relevant only for sys authentication
That's incorrect.
The username is used by other modules, at least sqlite / mysql, multifile, u2f, ldap / ldap3 / gss / kerberos* and maybe others.
it's not clear to me how you managed to connect an HTML5 client to it.
The machine where I started Xpra server also has Xpra system proxy server on port 14500. So no need for tcp sockets - I have just verified that regular domain socket Xpra server can be easily connected via Xpra proxy by HTML5 client