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