how about auth users without a password?

jw schultz jw at pegasys.ws
Wed Jan 21 17:54:06 GMT 2004


On Wed, Jan 21, 2004 at 07:26:50AM -0800, Larry Brasfield wrote:
> Jim Salter wrote:
> > Wouldn't this (accomplishing security restrictions without need to enter 
> > a password, or to enter a password more than once) be a lot more easily 
> > accomplished by simply using SSH transport and public/private keys 
> > instead of using the daemon mode at all?
> 
> Sorry to be unclear.  I am using SSH transport.  In fact, I do
> not have the daemon running or rsync's favorite port operating
> under inetd's province.  An example might be clearer.
> 
> I have CVS access setup so that clients use SSH to get in to the
> server, but then CVS configuration and Linux filesystem permissions
> (on the repositories) are used to control who can actually perform
> various operations on which repositories.  This limitation is
> effected regardless of how somebody invokes CVS.  Clients use SSH
> public/private keys, with the aid of a key agent if they like, to
> get past sshd with whatever limits their shell (from /etc/passwd)
> imposes.  There is no password entry phase at all, and if they use
> a key agent, repeated access is very convenient.
> 
> I hope to manage rsync access the same way.  Clients would be
> forced to come in via SSH (because no other ports are open), and
> once in, the configuration of rsync will determine what they can
> do, precisely.  This is just a hope at the moment because when I
> try to limit per-user access via rsyncd.conf, it still demands a
> password even though the user in question has already been
> authenticated to permit their SSH entry.
> 
> Perhaps I'm being anal about this, but I intend to impose some
> modularity on server access.  SSH does authentication and early
> screening of known users (and encrypts the channel), while the
> various services are responsible for fine-grained access control.
> I don't want rsync's authentication, just its per-user control.

It sounds like what you want to do is run the rsync daemon
over ssh.  That way ssh would do user authentication and
identification.  Identification would be disabled in the
rsyncd.conf files and no passwords would be requested by
rsync (anonymous rsync).

If you needed broader priveleges than were provided by
running the daemons as the users themselves you could use
the ssh ssh forced command facility with explicit selection
of rsync config files.

> 
> --
> Larry Brasfield
> 
> > Jim Salter
> > 
> >  > Larry Brasfield wrote:
> > > Hi, from a generally pleased new rsync user.
> > > 
> > > I have setup a number of services to be accessible via SSH.
> > > For most of them, it has been possible to arrange that clients
> > > can use a key agent and ssh's level 2 protocol to gain access
> > > without the need of entering passwords more than once, at
> > > the start of a session (assuming their keys are not stored in
> > > the clear).
> > > 
> > > Most of these services can be setup to restrict specific users
> > > to specific subsets of the potentially available access.  With
> > > rsync, this appears to be feasible using the "auth users"
> > > configuration item in rsyncd.conf, but in my efforts so far,
> > > this always results in a password prompt.
> > > 
> > > So, this is either a question or a suggestion.
> > > 
> > > How can I use rsyncd.conf to limit module access to specific
> > > users (or groups, preferably) without inducing rsync to demand
> > > a password?  If this is not presently possible, I suggest that a
> > > nice enhancement would be to make it possible via some device
> > > such as a '*' in the associated password entry.  This might be
> > > limited to rsync invocations by a currently authenticated user
> > > (such as occurs with SSH access) and disallowed for the "listen
> > > on rsync's port" mode of operation.
> > > 
> > > I would like to use SSH to authenticate users and grant access
> > > to the machine, leaving more specific rights management to the
> > > configuration of individual services.  With rsync, these functions
> > > appear to be a bit more intertwined than they have to be.
> > > 
> > > If people think this is a good idea, (especially the "owners" of
> > > rsync), I would be happy to revise the code to make it work.
> > > Let me know at
> > >    larry nospacehere brasfield at m s n dot com
> > > and I will post the results to this list/thread after a week or so.
> > > 
> > > --
> > > Larry Brasfield
> --
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
> 

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt


More information about the rsync mailing list