Developers word on SFTP/SCP chroot'ing?

Nick Lange nicklange at wi.rr.com
Tue Oct 22 00:56:05 EST 2002


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





More information about the openssh-unix-dev mailing list