rsync over ssl (again)

[tim.conway at philips.com]

How about using the command field in the authorized_keys file, to restrict 
them to sftp-server only?

Tim Conway
tim.conway at philips.com
303.682.4917 office, 303.921.0301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, caesupport2 on AIM
"There are some who call me.... Tim?"




Phil Howard <phil at ipal.net>
Sent by: rsync-admin at lists.samba.org
08/22/2002 10:32 AM

 
        To:     Ben Escoto <bescoto at stanford.edu>
        cc:     rsync at lists.samba.org
(bcc: Tim Conway/LMT/SC/PHILIPS)
        Subject:        Re: rsync over ssl (again)
        Classification: 



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/    |
-----------------------------------------------------------------
-- 
To unsubscribe or change options: 
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html