openssh unix dev - Oct 2002 - Developers word on SFTP/SCP chroot'ing?

Hello all,
    I've taken a brief skim of the archives available on theaimsgroup and
talked
to some others regarding the ideas on chroot SSH/SFTP/SCP functionality.
I've
also investigated a few of the various patches out for chroot sftp|scp|ssh and
am a bit of a loss at finding 'an elegant solution' to the problem.
Bearing in mind the excellent starting ground of John Furman's chroot ssh
patch.
Long story short I see three options:
	1. Remove the "stupidity" of scp/sftp and make them smart [i.e. read
configuration files, determine acl etc]. I've looked at this approach and
it's
not pretty. I don't like it from a "getting it done perspective".
The amount of
code etc to allow these applications to chroot themselves just doesn't seem
pretty. But it might be the right way to go, hence why I ask.
	2. Keep multiple copies of the sftp/scp binaries in each users jail to be
executed after the chroot by sshd. On massive user bases I see this as an minor
diskspace issue [~50K extra per jailed user], not to mention scripting all the
appropriate updates.]; furthermore, In my specific case at least, in the event
of allowing a user into a valid [but jailed, stripped down ] shell, scp needs to
be neutered to prevent it from copying remote to remote or local to remote. This
requires creating a custom version of scp, nothing to terrible. But a more
complex setup nonetheless.
	3. Finally, there is locking down around ssh, i.e. chroot /chroot/sshdserver
and have all users hit that copy. I don't like keeping seperate
authorization
etc, which is why I'm less inclined to see this as an option.

My case against the last option, is that users are allowed to know more
information than I care to give them :) While they may not have permission to go
into another users homedir, they can still *see it*, which I don't think
*needs*
to be if there is an elegant way to integrate chroot into SFTP/SCP/SSH codebase.
   While I will be coding for our specific needs here, if I can offer the code
after the fact to the masses in a useful fashion I'd like to do so, and for
that
reason I ask the programmers what, if any, approach would prove more beneficial
to everyone else.
Have a good day all,
Nick Lange

You missed option 4 for which most of the developers agree is the correct
one.

Write a shell to handle whatever customized features you need.  I've seen
one or two sftp/scp only shells floating around.  I'm sure they can be
modified for your needs.

- Ben

On Mon, 21 Oct 2002, Nick Lange wrote:
> Hello all,
>     I've taken a brief skim of the archives available on theaimsgroup
and talked
> to some others regarding the ideas on chroot SSH/SFTP/SCP functionality.
I've
> also investigated a few of the various patches out for chroot sftp|scp|ssh
and
> am a bit of a loss at finding 'an elegant solution' to the problem.
> Bearing in mind the excellent starting ground of John Furman's chroot
ssh patch.
> Long story short I see three options:
> 	1. Remove the "stupidity" of scp/sftp and make them smart [i.e.
read
> configuration files, determine acl etc]. I've looked at this approach
and it's
> not pretty. I don't like it from a "getting it done
perspective". The amount of
> code etc to allow these applications to chroot themselves just doesn't
seem
> pretty. But it might be the right way to go, hence why I ask.
> 	2. Keep multiple copies of the sftp/scp binaries in each users jail to be
> executed after the chroot by sshd. On massive user bases I see this as an
minor
> diskspace issue [~50K extra per jailed user], not to mention scripting all
the
> appropriate updates.]; furthermore, In my specific case at least, in the
event
> of allowing a user into a valid [but jailed, stripped down ] shell, scp
needs to
> be neutered to prevent it from copying remote to remote or local to remote.
This
> requires creating a custom version of scp, nothing to terrible. But a more
> complex setup nonetheless.
> 	3. Finally, there is locking down around ssh, i.e. chroot
/chroot/sshdserver
> and have all users hit that copy. I don't like keeping seperate
authorization
> etc, which is why I'm less inclined to see this as an option.
>
> My case against the last option, is that users are allowed to know more
> information than I care to give them :) While they may not have permission
to go
> into another users homedir, they can still *see it*, which I don't
think *needs*
> to be if there is an elegant way to integrate chroot into SFTP/SCP/SSH
codebase.
>    While I will be coding for our specific needs here, if I can offer the
code
> after the fact to the masses in a useful fashion I'd like to do so, and
for that
> reason I ask the programmers what, if any, approach would prove more
beneficial
> to everyone else.
> Have a good day all,
> Nick Lange
>
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>