Re: Setting permissions of ssh access
- From: Scott Haneda <talklists@xxxxxxxxxx>
- Date: Mon, 26 Oct 2009 15:40:15 -0700
Yes, my main goal is to use rsync-backup once I have a good test case going. I spent a lot of time on OS X getting two machines to talk to each other with passwordless logins and using a root account. I was pulling the backup from the client, to the server.
I went by this article, which expressly states that push backups are not the way to go:
It struck me as odd as well, and I am going to go back to pushing the data from the machines out to the single backup machine, which I can section off to not even be accessible to the outside world.
As I go through this process, I will document it, as there were some pretty strange thins happening with sshd_conf and not letting me have a root login.
Thanks for your comments, as soon as I have more, I will follow up.
Scott * If you contact me off list replace talklists@ with scott@ *
On Oct 26, 2009, at 11:04 AM, Quintin Beukes wrote:
Rather PUSH backups. This way you can
1) Close the backup machine to allow ONLY access from the specified
machines on an IP/MAC bases (since it's local net)
2) You don't have to open up root access for any machines
3) You can have the rsync client run as root to allow it to copy all
files on it's own machine, then copying it to a lower access user on
the target machine.
If you want your backup files to be stored with the same
ownership/permissions as on the source machine, you would have to
login as root on the backup machine. If it's closed from outside
access this is safer than allowing root access to your public machine.
Further restricting it by IP/MAC makes this even more secure.
If using something like rsync-backup, you're basically running a
static command on the backup server's side, which provides an extra
level of security if you want to have the backup server side execute
as root as well. Let me explain it like this:
1) You have the source machine S - it's public
2) You have the machine machine B - it's completely closed up and only
allows IP/MAC level filtering on incoming port 22 from machine S
3) On machine B you have a root account with a password for you to login
4) You want machine S to use this root account to copy it's backups
5) You use rsync-backup wrapped in ssh to do this. This means you have
2 commands run by ssh, the rsync-backup client command and
rsync-backup server side command
6) You setup a public key on the root account on machine B, which is
only allowed to run a single command, the rsync-backup command. This
means rsync-backup authenticates using the public key, but is only
allowed to run a fixed command, which is the one it uses to copy the
backups. So it is authenticated as root, which allows you to copy all
types of ownership/permissions, even setuid bits, but you can't do ANY
other than what rsync-backup command and it's protocol allows.
Have you heard of rsync-backup? It's a utility which uses rsync's
libraries, but provides common backup features like exclusions,
incremental backups + increment management, etc. The technique listed
above is what I use to make all my backups. It's really simple, works
brilliantly and with the specified would be very secure as well. Since
it's running as root there is always the risk of exploitation to gain
root access, which could cause compromise of your other machines,
though it's already very secure and always possible to add extra
levels of security.
On Fri, Oct 23, 2009 at 9:28 PM, Scott Haneda <talklists@xxxxxxxxxx> wrote:Hello, I've looked around and found a few different approaches to this.
Looking for a discussion of the pros, cons, and best practices.
I want to use rsync over an ssh connection to clone one machine to another.
This means one end will need root login.
Right now I have passwordless keys to allow myself to login. Root login is
Would an acceptable method be to allow root login from a specific IP
address? Or is there some other way to allow root privilege use between a
source and destination host without opening it up by IP?
This is for backups, and only ever will be machine to machine, same subnet.
I'm not immediately seeing how to set granular permissions based on
conditions like IP, MAC, or other harder to spoof credentials.
I'd it better to pull backups or push backups, or equivalent?
The backup machine could be made to have no public access at all. Thanks for
Iphone says hello.
- Prev by Date: Re: Setting permissions of ssh access
- Previous by thread: Re: Setting permissions of ssh access