[scponly] scp failing in chrooted environment

James Boorn jboorn at pivotlink.com
Thu Apr 14 12:44:36 EDT 2005


That is why I build a chroot scp and sftp.  Get the source for openssh,
comment out the switches and code you don't want supported (I originally
did this to disallow downloads, and only allow uploads) and install the
binaries you build in the chroot.

On Thu, 2005-04-14 at 08:58 -0700, Kaleb Pederson wrote:
> Assuming I understand the question correctly, the security risks come in when 
> files are being downloaded from a machine running scponly, rather than being 
> uploaded.
> 
> When scp is used, the commandline that is being issued has to be parsed by 
> scponly to make sure that it doesn't contain certain things. eg. -S 
> (encryption command) for scp or sftp.
> 
> If there were a bug in the scp commandline parsing, somebody might be able to 
> sneak in a -S unmolested, and thus be able to run a command on the remote 
> server.... for example, if they were able to somehow pass in "-S nmap 
> 1.0.0.0-100.0.0.0", they might be able to cause some problems, etc.
> 
> With sftp, all the wildcards are interpreted by SFTP, rather than scponly, so 
> it has been very well tried and tested.
> 
> --Kaleb
> 
> On Thursday 14 April 2005 8:47 am, Paul Hyder wrote:
> > Sort of like programming languages, all you need is FORTRAN ;-)
> >
> > Supporting users choices does add complexity.  Our cluster has
> > people with lots of existing large scripts that use scp, sftp,
> > and rsync and so we get to live with that complexity.  Choice is
> > a good thing.
> >
> > BTW: What would make "scp $thefile user at host:incoming" more "risky"
> > than an equivalent sftp?
> >      Paul Hyder
> >      NOAA Forecast Systems Lab
> >      Boulder, CO
> >
> > Kaleb Pederson wrote:
> > > On Wednesday 13 April 2005 6:46 pm, Ralf Durkee wrote:
> > >>For Unix systems how about just scripting with the -b option, something
> > >>along the lines of ...
> > >
> > > Yes.... or you could do something like the following:
> > >
> > > MYFILE=blah.${ext}
> > > sftp user at host <<EOF
> > > cd /path
> > > put $MYFILE
> > > ...
> > > EOF
> > >
> > > --Kaleb
> > >
> > >>TMPFILE=`mktemp -t progname` || exit 1
> > >>echo "put test.txt incoming/test.txt" > $TMPFILE
> > >>sftp -b $TMPFILE scpuser at example.rd1.net:.
> > >>rm $TMPFILE
> > >>
> > >>It's a small inconvenience that seems well worth the reducing additional
> > >>complexity and risk.
> > >>
> > >>-- Ralf Durkee, CISSP, GSEC, GCIH
> > >>http://rd1.net
> > >>
> > >>At 11:35 AM 4/13/2005, Paul Hyder wrote:
> > >>>It turns out that scp, running under sshv2 since we also don't permit
> > >>>sshv1, is
> > >>>sometimes a very useful tool, e.g. in *NIX shell scripts that automate
> > >>>file transfer.
> > >>>    Paul Hyder
> > >>>    NOAA Forecast Systems Lab
> > >>>    Boulder, CO
> > >>>
> > >>>Ralf Durkee wrote:
> > >>>>At 01:19 PM 4/11/2005, Paul Jones wrote:
> > >>>>>I have set up scponly and it is almost working perfectly.  I use it
> > >>>>> with the chroot option.  rsync works, sftp works, but scp does not.
> > >>>>> scp complains: "unknown user 10001"  10001 is the correct user id.  I
> > >>>>> am thinking that I have just left something out the the chrooted area
> > >>>>> that it needs, but I can not figure out what.  usr/bin/id,
> > >>>>> usr/bin/groups, usr/bin/scp are all there.  Any thoughts about what
> > >>>>> might be wrong?
> > >>>>>
> > >>>>>Paul
> > >>>>
> > >>>>I don't understand why anyone would want to go to all the extra work
> > >>>> and risk to make the scp1 protocol work, when you've got the sftp
> > >>>> protocol working. All of the scp clients I have tried will use the
> > >>>> sftp protocol just fine.  I don't see the benefit of having the higher
> > >>>> risk protocol, when the sftp protocol is much easier to control and
> > >>>> verify, and requires a simpler and smaller chroot.  I configure my SSH
> > >>>> server to only use SSHv2 as SSHv1 has some known weaknesses, and then
> > >>>> compile scponlyc to only use the sftp protocol.
> > >>>>
> > >>>>-- Ralf Durkee, CISSP, GSEC, GCIH
> > >>>>Principal Consultant
> > >>>>http://rd1.net
> > >>>>_______________________________________________
> > >>>>scponly mailing list
> > >>>>scponly at lists.ccs.neu.edu
> > >>>>https://lists.ccs.neu.edu/bin/listinfo/scponly
> > >>
> > >>_______________________________________________
> > >>scponly mailing list
> > >>scponly at lists.ccs.neu.edu
> > >>https://lists.ccs.neu.edu/bin/listinfo/scponly
> > >
> > > _______________________________________________
> > > scponly mailing list
> > > scponly at lists.ccs.neu.edu
> > > https://lists.ccs.neu.edu/bin/listinfo/scponly
> >
> > _______________________________________________
> > scponly mailing list
> > scponly at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/scponly
> 
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly




More information about the scponly mailing list