mouring at offwriting
Feb 7, 2012, 12:43 PM
Post #5 of 7
(594 views)
Permalink
|
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.
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.
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
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|
