scp -f / interactive ?

[Hank Leininger]

On 2000-12-24, "Richard E. Silverman" <res at shore.net> wrote:

> On Sun, 24 Dec 2000, Philipp Buehler wrote:

> > debug: Sending command: scp -v -f file.txt
> > debug: Entering interactive session.
> > Sending file modes: C0644 3093316 file.txt
> > 
> > Since it 'interactives' the remote user needs a shell.
[snip]
> > Any workaround?

> No, because sshd uses the remote user's shell to run any program it
> needs to start, via "$SHELL -c <program>".

Well, depending on what qualifies as a "workaround," yes there is.  If, for
instance, you want user 'foo' to only ever access drop directories to
upload or download files, and your goal is to be able to keep that account
from getting access to a regular shell (via ssh or other usual means), you
can:

-Use RSA/DSA authentication only
-Give the user 'foo' their own group 'foo'
-Make their home directory owned by root.foo and mode 710 or so; this
  prevents .forward, .shosts, etc tricks
-Make their .ssh and .ssh/authorized_keys{,2} files root.foo, not writable
  by group foo
-Create a ~foo/in directory which is root.foo mode 1730
-Use an RSA or DSA public key with 'command="scp -t in"' in authorized_keys
  and all other fun things disabled (no-pty,no-*-forwarding, etc), using
  that identity to start uploads[0]
-Create a ~foo/out directory which is root.foo mode 750
-Use a public key with 'command="scp -f out/*"', using that identity to
  start downloads[1]
-Set environment="PATH=/path/to/sshbins" in the authorized_keys entries
  for paranoia's sake, since 'scp' gets started w/no path specified
-Lock the user's password in the shadow file (simply put in a '*', etc),
  this blocks conventional login methods as well as forcing RSA/DSA auth
  via the specially crafted authorized_keys files
-If possible, add from="..." tokens to the authorized_keys files to only
  allow transfers to/from a set of possible addresses
-Optionally, write a small "shell" wrapper which checks the parent process
  is sshd, allows only the arguments '-c scp (-t in|-f out/*)', and exits 
  w/error code if started up any other way.  A small, properly paranoid
  perl script would do.  ("Doing it right" in C would probably be a nice
  contrib-able project for some student.)  This will further block
  conventional access to the account.

This'll result in an account which can upload and/or download files into
subdirectories of their home directory, and nothing else.  To make life
easier, you *may* want a third identity whose key has a command="..." which
renames 'in/tmpfile' to 'done/tmpfile'.  This makes it easy to tell,
lazily, when a file is done being uploaded simply by checking for its
existance in 'done' as opposed to fuser'ing it and checking when scp is
done writing to it in 'in'.[2]

Besides the obvious caveats, does anybody see anything fundamentally wrong
with the above (besides that it sounds complex and painful; really it isn't
after the first or second time ;) ?

Bonus points for using the chroot patch for sshd
( http://marc.theaimsgroup.com/?t=97237758900001&r=1&w=2 ) and arranging
for the scp to be done chrooted under their home directory, especially
since scp still has the "evil server can cause writes to arbitrary files"
bug -- see
http://marc.theaimsgroup.com/?l=bugtraq&r=1&s=scp+file+transfer+hole&q=b
(I've just verified that 2.3.0p1 running either protocol 1 *or* 2, contrary
to the discussion at the time, is vulnerable).  I have to wonder if a
client couldn't fool the server into doing the reverse--feeding it and/or
writing to files not requested on the command line and thus screened by the
command="..." and/or custom shells.  Of course the chroot env setup would
take a bit more work (static wrapper shell && scp in /home/foo/bin/, etc).

[0 Many of these things ought be done in /etc/sshd_config anyway on a
   "trust no one" box--sshd should turn off various forwardings, set only
   RSAAuthentication, etc.  But they won't hurt to put in the keys files
   as well. ]

[1 AFAIK the path/file being downloaded will be in scp's command line,
   so must be present in the command="..." entry.  This is the best
   workaround for transferring arbitrary filenames and not having to use
   either one fixed name, or keeping multiple downloader authorized_keys
   entries around that I can think of.  While it's fugly, I don't think it
   really adds risk (though it does require that the download dir be
   readable...).  It'd be nice if there was a cleaner way... anyone?  A
   fake wrapper shell could perhaps enforce this more elegantly, but it'd
   be nice if it didn't have to, since ssh's command="..." *almost* gets
   it perfect. ]

[2 This of course creates the "but then I can only upload one file at a
   time" problem.  Oh well, nothing's perfect... make the wrapper shell
   able to do this more generally (rename in/*, etc), I guess. ]

--
Hank Leininger <hlein at progressive-comp.com>