On 22 Nov 18:03, Chris G wrote:
On Mon, Nov 22, 2010 at 05:04:31PM +0000, Brett Parker wrote:
As I said I want to be able to use this mode to some systems where I have shell access but not root access. I guess I could set up an extra ssh login which uses a passphraseless key but only starts an rsync daeomon process but I was wondering if there might be a way to set up a sort of user (i.e. non-root) sort of inetd.conf.
No. Only root can do inetd.conf. And that has to listen to the port and then spawns off a new process. You could run a copy of inetd as your own user, but why bother.
Well yes, I realise that, I was just asking if there's an easy way to have an unprivileged user start a process when a connection is received on some specific (obviously unprivileged) port.
Are you trying to say that it's safer to push over an unencrypted rsync daemon than it is to use a passphraseless ssh key with command= set in the authorized_keys?
I see little difference given the likely possible attacks. It's just rather easier (IMHO) to go the rsync route.
Erm, except there's no authentication involved in the rsync:// route? And the rsync daemon has been found buggy many times?
The only users I know of the "real" rsync daemon these days are people distributing things, and they do it read only.
With a little bit of lateral thinking that's actually how I think I can implement what I want. Instead of running the rsync daemon on the remote system where I just have shell access I can run an rsync daemon on my home server with everything set read only and then the remote systems can 'pull' the backups across.
Someone breaking in to the server end can't damage the remote files, or at least they could if they overwrote all the files but it's a fairly unlikely scenario IMHO. A break-in on the remote system can obviously delete the backup but will have no access to the server.
Or just do what anyone else would, and use a passphraseless ssh key with a correct limiting command in the authorized_keys file. Thus not transfering data in plain text across the interwebnets, and not trusting to the security of the rsync daemon.