how about auth users without a password?

[Larry Brasfield]

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.

--
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