Suggestion for openssh

[John Olsson M]

Ben Lindstrom wrote:
> It would be more useful to allow "Subsystem"  be allowed in a
> 'Match' section and ensure 'Subsystem sftp none'  or such to
> remove it from the user's valid subsystem support.

I'm strongly in favor of such an enhancement of OpenSSH. This would also allow for setting a chroot jail per individual subsystem. E.g. sftp chroot:ed but not ssh. :)

See also https://bugzilla.mindrot.org/show_bug.cgi?id=1975


/John

-----Original Message-----
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Ben Lindstrom
Sent: den 7 februari 2012 21:44
To: paulo.henrique at cptec.inpe.br
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Suggestion for openssh


On Feb 7, 2012, at 6:04 AM, Paulo wrote:

> Hi!
> 
> I do not know if it's the ideal place, but I'm sending some suggestion.
> Always use openssh and its enormous features.
> 
> - I needed to create an environment with only sftp access and thus used:
> 
>   - Match User suporte
>         ForceCommand / usr / lib / openssh / sftp-server
> 
>   OK! It worked perfectly! But only sftp.
> 
> - Create an environment with only blocking the ssh,  but scp and sftp 
> access, I used:
>     - Rssh;
>     - Mysecureshell;
>     - Scponly.
>   Work, but change  my SHELL, and also created another
>   environment for authentication and this is not good.
> 
> 
> So I suggest to you developers  the following idea:
> - Create the following options to sshd_config:
>    - DenyCmdssh
>    - DenyCmdscp

This is kinda bogus.. "scp" is just a normal program.  All the scp command does is the moral equiv of:

tar -cvf .. | ssh .. tar -xvf 

So that deny command isn't possible unless you are looking to block the whole ability to run remote commands.  Which has been discussed and the decision was long ago to let it be a shell level issue.  As there is no really good way of handling this.  Even if the user has a normal shell they can still bluff this behavior via expect scripts.

>    - DenyCmdsftp

This is also bogus because if you deny "sftp" but allow "scp"  one can still
do:  sftp -1 ...   which will act like how scp works by ignoring the subsystem
definitions.


Still, not useful to deny subsystems if you still give them access to run remote commands.


>  All three options above with default value "no".
>  If I want to scp access only could perform the following configuration.
> 
>     - Match User suporte
>             DenyCmdssh yes
>             DenyCmdsftp yes
>             DenyCmdscp no

I see above as why this wouldn't block "scp"  and why you really need to do it via the shell level.

You can look through the history of this mailinglist.  This isn't the first time this has come up, and I doubt it will be the last, but in truth this isn't a problem that can be neatly solved in sshd and there are times it is just better to manage it via 3rd party tools.

- Ben

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev