chrooting/jailing transfer-only accounts

[Ben Lindstrom]

On Wed, 22 May 2002, Sandor W. Sklar wrote:

> At 9:20a -0500 5/22/02, Ben Lindstrom wrote:
> >I'm sorry but I know I don't read binhex.
>
> sorry bout that; I've pasted the script below (and attached it with
> mime-encoding.)
>
> >
> >But assuming you did what has been discussed here before  which is wrote
> >some from of program that detects the -c argument passed to it and accept
> >or deny the commands.  This can work for sftp-server also.  Because we
> >do ${SHELL} -c sftp-server just like one would expect.
>
> Right, but when using (openssh) scp, the $SSH_ORIGINAL_COMMAND
> contains "scp", and one of several arguments, and the name (or names)
> of the file(s) being transferred.  Thus, it is easy to break up that
> command and modify it on the server-side.  I see no equivalent way of
> doing so when the server is spawning the sftp-server.
>

[..]
> In that .ssh directory, place the user's public half of their keypair
> into the file "authorized_keys".  THIS IS IMPORTANT: insert, on the
> same line as the key, before the key, the text:
> command="/path/to/scpjail".  This is important, because it restricts
> any use of this key to the execution of this scpjail script, no
> matter what the user tries to do.
>

Why?

Why don't you just change the user's shell to /path/to/scpjail ?  By doing
it this way you capture all subsystems, standard logins and remote
commands by just reading the command line and looking at anything past
the first -c.  I don't see a reason why one needs to use command="".

The other question is should SSH_ORIGINAL_COMMAND reflect subsystem calls?

- Ben