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.
On Mon, Dec 23, 2019, 12:58 PM Antoine Martin via shifter-users < shifter-users@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@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 > >>> someu...@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@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@lists.devloop.org.uk > >>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>> > >>>> > >>>> _______________________________________________ > >>>> shifter-users mailing list > >>>> shifter-users@lists.devloop.org.uk > >>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>> > >>> _______________________________________________ > >>> shifter-users mailing list > >>> shifter-users@lists.devloop.org.uk > >>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>> > >> > >> _______________________________________________ > >> shifter-users mailing list > >> shifter-users@lists.devloop.org.uk > >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users@lists.devloop.org.uk > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users@lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users
