Developers word on SFTP/SCP chroot'ing?

[Ben Lindstrom]

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
>