This patch is a draft that enable to select a session through a proxy.
the documented --display seems to not exist, thus I implemented one here
Best regards
patch that implement --target-session
/!\ Author WARNING this patch is unsecure with PAM auth /!\
use with caution
Here are some of the issues we need to think about:
TODO: use ssh-askpass when needed" - that should already be the case, see also the --exit-ssh and --no-exit-ssh flags (#380 and #203). In any case, reading from stdin does not belong here.
def init(opts) to pam_auth.py? is it broken and I haven't noticed? (if so, this is unrelated and should have been a blocker bug for 0.13 ...)
Replying to totaam:
Here are some of the issues we need to think about:
- should the client even be allowed to specify the exact session to connect to? (this would allow the proxy to be used as a way to bypass any firewall restrictions to at least turn it into a port scanner)
When I created this patch I thought about ssh, ssh allow any tunnel by default to any host. I thought it is a question of setup (may be xpra proxy could have a white list or iptables and so on. This is also important to note that proxy authenticate the user which limit the abusive use of the proxy, and that make an udge difference from HTTP proxy.
- what is the use case scenario? maybe we can find a way to achieve the result without giving away so much control?
The scenario is an easy setup, user has no complicated setup to do. Another case is if you have several computer, and add a new one, no proxy update is required.
I also thought about another way by using a mapping between virtual_host -> real host, but this make more complicated setup with no real benefits. (see ssh tunnel comments)
I will look at those ticket, I agree this part of the patch his out of scope of this ticket.
- why add
def init(opts)topam_auth.py? is it broken and I haven't noticed? (if so, this is unrelated and should have been a blocker bug for 0.13 ...)
If I did it this is probably because I got an error, but while I'm not totally aware of every thing happening within xpra, I may made a bad command line.
- assuming that we do really need this change in its current form, it would still need man page updates and wiki updates (but let's not worry about this just yet)
Yes
I will review this patch, but I would like to do it after #172 is resolved
ssh allow any tunnel by default to any host
It is usually the case, but not necessarily so: sshd can be configured not to allow port forwarding (see AllowTcpForwarding - which alone is not sufficient.. netcat and friends..).
proxy authenticate the user
Again it is usually the case, but one can configure a proxy to serve only specific sessions and one may choose to do so without requiring authentication. Or use authentication, but restrict the server in other ways, and this blows the door wide open. Caution is advised.
xpra proxy could have a white list ..
Allowing the user to specify the session is potentially such a huge gaping hole, that something would have to be done to prevent problems before merging I think. Either using a whitelist, or even disabling the functionality by default (which would force the admin to RTFM).
I did it this is probably because I got an error
pam_auth was indeed broken, fixed for trunk in r6563 and v0.12 / v0.13 in r6564.
I would like to do it after #172 is resolved
Fine with me... there's a lot more to solve there!
Any update on this? Can I close it?
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/576