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

[Antoine Martin]

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
>