Is there any way to do the equivalent of running rsync from an entry in inetd.conf that can be done by a non-provileged user?
I want to run rsync from cron to backup files to a couple of places where I have shell logins (but not the privilege to make additions to inetd.conf).
I suppose I could just run rsync in daemon mode using a cron job on the remote system (and kill it later) at the right time but that seems a little crude.
On 22 Nov 14:50, Chris G wrote:
Is there any way to do the equivalent of running rsync from an entry in inetd.conf that can be done by a non-provileged user?
I want to run rsync from cron to backup files to a couple of places where I have shell logins (but not the privilege to make additions to inetd.conf).
I suppose I could just run rsync in daemon mode using a cron job on the remote system (and kill it later) at the right time but that seems a little crude.
rsync with it's transport set as ssh will automagically start a daemon on the remote end as the user you're running as, so I'm not sure what you mean here...
I don't think I run a "real" rsync daemon anywhere, I simply let it do it's stuff over an ssh session.
On Mon, Nov 22, 2010 at 03:12:04PM +0000, Brett Parker wrote:
On 22 Nov 14:50, Chris G wrote:
Is there any way to do the equivalent of running rsync from an entry in inetd.conf that can be done by a non-provileged user?
I want to run rsync from cron to backup files to a couple of places where I have shell logins (but not the privilege to make additions to inetd.conf).
I suppose I could just run rsync in daemon mode using a cron job on the remote system (and kill it later) at the right time but that seems a little crude.
rsync with it's transport set as ssh will automagically start a daemon on the remote end as the user you're running as, so I'm not sure what you mean here...
I don't think I run a "real" rsync daemon anywhere, I simply let it do it's stuff over an ssh session.
If you look at the man page for rsync it makes a very clear distinction between two modes of operation:-
First the mode you (and I) use most of the time which makes an ssh connection to the remote and starts rsync at the remote end via the ssh connection.
Second (what I want to use) a mode that communicates via port 873, see the section which starts with "It is also possible to use rsync without a remote shell as the transport."
This second mode has a big advantage, you don't need any sort of passwordless ssh login if you want to run unattended backups via cron or similar. I already use it to backup to my local backup server (where I have root access of course) as it means there is no passwordless access possible to the backup system even if someone gains access to my system.
The syntax uses :: to indicate this mode, e.g.:- rsync -a /var/www backup::chris/var
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.
On 22 Nov 15:48, Chris G wrote:
On Mon, Nov 22, 2010 at 03:12:04PM +0000, Brett Parker wrote:
On 22 Nov 14:50, Chris G wrote:
Is there any way to do the equivalent of running rsync from an entry in inetd.conf that can be done by a non-provileged user?
I want to run rsync from cron to backup files to a couple of places where I have shell logins (but not the privilege to make additions to inetd.conf).
I suppose I could just run rsync in daemon mode using a cron job on the remote system (and kill it later) at the right time but that seems a little crude.
rsync with it's transport set as ssh will automagically start a daemon on the remote end as the user you're running as, so I'm not sure what you mean here...
I don't think I run a "real" rsync daemon anywhere, I simply let it do it's stuff over an ssh session.
If you look at the man page for rsync it makes a very clear distinction between two modes of operation:-
First the mode you (and I) use most of the time which makes an ssh connection to the remote and starts rsync at the remote end via the ssh connection. Second (what I want to use) a mode that communicates via port 873, see the section which starts with "It is also possible to use rsync without a remote shell as the transport."This second mode has a big advantage, you don't need any sort of passwordless ssh login if you want to run unattended backups via cron or similar. I already use it to backup to my local backup server (where I have root access of course) as it means there is no passwordless access possible to the backup system even if someone gains access to my system.
The syntax uses :: to indicate this mode, e.g.:- rsync -a /var/www backup::chris/var
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.
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?
The only users I know of the "real" rsync daemon these days are people distributing things, and they do it read only.
Hmm.
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.
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.
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.
On Tue, Nov 23, 2010 at 10:10:15AM +0000, Brett Parker wrote:
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.
Sleeping on it I have (I think) an even simpler (and at least as secure) solution. Don't use cron/anacron, just run a script from my .profile which runs the rsync at hourly intervals (or whatever seems reasonable).
Since it runs with the environment of my login it can make passwordless connections to the remote system (without a need for extra passphraseless ssh keys).
Other (more system oriented) backups are done by other means anyway, this extra rsync is of business records which will only change as a consequence of me changing them so backing up only while I'm logged in is fine.
-
Brett Parker -
Chris G