rsync over ssl (again)

[Phil Howard]

On Thu, Aug 22, 2002 at 09:05:47AM -0700, Ben Escoto wrote:

| >>>>> "PH" == Phil Howard <phil at hamal.ipal.net>
| >>>>> wrote the following on Thu, 22 Aug 2002 09:37:03 -0500
| 
|   PH> Fortunately things like pop3 and imap4 have secure equivalents.
|   PH> But I also have a need to give users the ability to upload and
|   PH> download their own data securely, and the only good tool to do
|   PH> that without granting them something that might open a shell for
|   PH> them is https.  But for large transfers, that just does not work
|   PH> very well, and I think rsync would be a much better answer if
|   PH> the security issue can be worked out.
| 
| I've been curious about this too.  Is there something wrong with sftp?
| It sounds like it does what you want.  It is part of the openssh
| package, so it is probably secure, but I haven't heard much about it.

=============================================================================
NAME
     sftp-server - SFTP server subsystem

SYNOPSIS
     sftp-server

DESCRIPTION
     sftp-server is a program that speaks the server side of SFTP protocol to
     stdout and expects client requests from stdin.  sftp-server is not
     intended to be called directly, but from sshd(8) using the Subsystem
     option.  See sshd(8) for more information.
=============================================================================

While it is "secure" in the sense of an encrypted medium, it is still
using a login to a system (e.g. /etc/passwd based) account.  I don't
have a trust that once authenticated in to the SSH layer, that there
isn't some way to defeat that and just get a shell.  I have read the
suggestion of using the shell path in /etc/passwd to force a user to
not have a shell, but there are just too many scenarios being opened
up here to really analyze.  SSH's security has focused on preventing
session tapping, session hijacking, MitM attacks, authentication
spoofing, and (espectially recently) credential access exploits.
But I just don't see any record or documentation of controlling what
an authenticated user is _authorized_ to do.  SSH is by legacy a tool
to provide a shell access.  I worry it could revert to that, either
due to a less focused initiative, or just the lack of any documentation
for administering _authorization_ aspects (as opposed to authentication).

How would I say what users are allowed to access what paths.  I can do
this in rsync via port 873 and thus /etc/rsyncd.conf, but there just
seems to be nothing in sftpd to do it.  And what in sftpd lets me do
what rsync can do in "secrets =" in /etc/rsyncd.conf?

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------