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>