[winswitch] SSH wrapper, was: Hi List, Quick Xpra question

Tue Dec 24 20:54:54 GMT 2019

Yeah. I think that with a "xpra start-or-attach --display=$userid" should
do about exactly what I want it to. Awesome, thank you. When might I be
able to see some supporting code in the repo? I'm excited.

On Tue, Dec 24, 2019, 10:04 AM Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> On 23/12/2019 21:48, Celeste Weingartner via shifter-users wrote:
> > Antoine,
> >
> > Now that I think about it I could change the command shell for those
> users
> > to a custom shell, and I think perhaps I could get the results I'm
> looking
> > for that way can you tell me if paramiko requests and interactive session
> > by default? Because I think without an interactive session the shell
> > specified for specific users in the password file might not fire.
> The SSH session is not interactive and does not request a pty, that's
> true of all the backends, not just paramiko.
> What I am suggesting instead is something like this:
> http://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
>
> Cheers,
> Antoine
>
> >
> > On Mon, Dec 23, 2019, 12:58 PM Antoine Martin via shifter-users <
> > shifter-users at lists.devloop.org.uk> wrote:
> >
> >> On 23/12/2019 01:10, Celeste Weingartner via shifter-users wrote:
> >>> I had considered tying it to user ID and that's a good idea. While
> >> changing
> >>> the remote xpra command is certainly an option I could write into the
> >>> frontend, I want this to be a bit more secure and not rely on the
> >> frontend
> >>> to do the right thing, is there a easy way to specify a new command
> >> server
> >>> side and system wide?or user group wide?
> >> No.
> >> The remote command is requested by the SSH transport (ie: paramiko
> >> openssh or plink), it is always specified by the client - that's just
> >> how SSH works.
> >>
> >> xpra's builtin SSH server already intercepts the 'xpra _proxy' command
> >> to avoid spawning a new subprocess unnecessarily. But modifying this
> >> behaviour is likely way too complicated for what you are trying to
> >> achieve. (and this would only work with xpra running as ssh server)
> >>
> >> If you want to limit what your users can execute via ssh logins then you
> >> should look into OpenSSH command restrictions and you can then place
> >> your override script in a whitelisted location, ie:
> >> /usr/local/bin/xpra
> >> To see which remote commands your clients will attempt to run, see:
> >> xpra showconfig | grep remote-xpra
> >>
> >> Cheers,
> >> Antoine
> >>
> >>>
> >>> Sorry for the double email Antoine
> >>>
> >>>
> >>> On Fri, Dec 20, 2019, 6:59 AM Antoine Martin via shifter-users <
> >>> shifter-users at lists.devloop.org.uk> wrote:
> >>>
> >>>> On 19/12/2019 16:19, Celeste Weingartner via shifter-users wrote:
> >>>>> im writing a frontend for Xpra that will use ssh to connect. I would
> >> like
> >>>>> to make a ultra persistant chrome session be remotely served..
> >>>> Running browsers through xpra seems to be a popular use case.
> >>>> Are you using xpra's builtin ssh server or are you allowing those
> users
> >>>> shell access on your server? (and restricting what commands they are
> >>>> allowed to run?)
> >>>>
> >>>>> Ive got
> >>>>> firejail working for chrome, and i can manually connect with xpra
> start
> >>>>> someuser at apphost.com --start-child='google-chrome' and that works..
> >> and
> >>>> i
> >>>>> can reattach to it no problem but if i reisssue another start, it
> >> starts
> >>>>> another x session, which i do not want.. I want it limited to one per
> >>>> user.
> >>>> An easy way to achieve that would be to derive the X11 display for
> each
> >>>> user from their user id. That way a user would only ever be able to
> >>>> start a single session.
> >>>> FYI: most browsers, including chrome, are limited to a single instance
> >>>> per user account.
> >>>>
> >>>> To make things easier to manage, we could add a new subcommand:
> >>>> "xpra attach-or-start"
> >>>> Or maybe a new flag:
> >>>> "xpra attach --create=yes"
> >>>> Or even:
> >>>> "xpra start --reuse-session=yes"
> >>>> Ideas and suggestions welcome.
> >>>>
> >>>> When connecting over ssh, the xpra client will run "xpra _proxy",
> >>>> potentially with extra arguments, and this is what connects the xpra
> >>>> server to the ssh channel.
> >>>> The remote xpra command can be changed using the "--remote-xpra="
> >>>> command line option.
> >>>> This would be a decent place to override the default behaviour and
> start
> >>>> a new server instance if one is not found, before trying to connect to
> >> it.
> >>>>
> >>>> Cheers,
> >>>> Antoine
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> max.
> >>>>>
> >>>>>
> >>>>> On Mon, Dec 16, 2019 at 6:06 AM Antoine Martin via shifter-users <
> >>>>> shifter-users at lists.devloop.org.uk> wrote:
> >>>>>
> >>>>>> On 16/12/2019 07:59, Celeste Weingartner via shifter-users wrote:
> >>>>>>> Hi Everyone, im not sure if the devel list would be the place for
> >> this
> >>>> or
> >>>>>>> not.. So i'll ask.
> >>>>>>>
> >>>>>>> Im trying to use Xpra to create an application server. For a
> specific
> >>>>>>> application. I do not want users to be able to spawn more than 1
> xpra
> >>>>>>> server process. I want them to be limited to 1. Short of disabling
> >>>> server
> >>>>>>> commands, and using firejail which im already doing, how can I
> >> further
> >>>>>>> limit it to one server per user?  Im willing to be there's some
> sort
> >> of
> >>>>>>> bash magic that can be done in the xpra startup, but im unsure
> where
> >> to
> >>>>>>> even begin there, im not a python coder... Bash I can do..  But can
> >>>>>> anyone
> >>>>>>> provide some pointers or tips?
> >>>>>> How are you going to start the sessions? Is it going to be on demand
> >> for
> >>>>>> each user?
> >>>>>> How are they connecting to the server? ssh?
> >>>>>> Are you going to give them a command line to run or an xpra URI they
> >>>>>> just click on?
> >>>>>>
> >>>>>> This is not the first time something like this has been requested,
> so
> >>>>>> maybe we can make it easier to setup.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Antoine
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks in advance,
> >>>>>>>
> >>>>>>> Celeste
> >>>>>>> _______________________________________________
> >>>>>>> shifter-users mailing list
> >>>>>>> shifter-users at lists.devloop.org.uk
> >>>>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> shifter-users mailing list
> >>>>>> shifter-users at lists.devloop.org.uk
> >>>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>>>>>
> >>>>> _______________________________________________
> >>>>> shifter-users mailing list
> >>>>> shifter-users at lists.devloop.org.uk
> >>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> shifter-users mailing list
> >>>> shifter-users at lists.devloop.org.uk
> >>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>>>
> >>> _______________________________________________
> >>> shifter-users mailing list
> >>> shifter-users at lists.devloop.org.uk
> >>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>>
> >>
> >> _______________________________________________
> >> shifter-users mailing list
> >> shifter-users at lists.devloop.org.uk
> >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >>
> > _______________________________________________
> > shifter-users mailing list
> > shifter-users at lists.devloop.org.uk
> > https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
>