Hello list, I have a requirement to script a sync from a server to a UNIX workstation (Mac OS X) users desktop and profile related data at logon and logoff. Rsync looks like it may be appropriate, but I am concerned about making a sufficiently secure connection between the server and the client (given my sync must be non-interactive). Rsh is not an option, so Ssh seems to be the only alternative. Now I'm quite familiar with Ssh, setting up public/private key pairs etc. but I'm quite uncomfortable about using this across hundreds of workstations to provide the sync functionality I'm looking for. Specifically my fear is if someone gains administrative access to their workstation and can access the ssh private key & ssh server key they will be able to access any data they want from the central file server. Plus relying on keypairs is very messy from an administrative point of view. I guess other people must have thought about a similar type of requirement in terms of security and was hoping I might get some pointers from those how have done this before. My personal preference was to mount a share from the file server on the client and essentially do the sync all locally on the client but rsync doesn't seem to like doing this very much (apparently this is advised against), any help gratefully recieved, thanks Andy.
> quite uncomfortable about using this across hundreds of workstations to provide the sync functionality I'm looking for. Specifically my fear is if > someone gains administrative access to their workstation and can access the ssh private key & ssh server key they will be able to access any > data they want from the central file server. Plus relying on keypairs is very messy from an administrative point of view.First off, if all you're trying to do is back up user data, you don't need to rsync into the file server as root - you can create individual unix users for each machine that's backing up. This is not a guarantee that it will be secure, but it might be good enough for you. I'm looking at the same problem although on a smaller scale. I haven't made a final determination yet as to how i'm going to proceed, but I am leaning toward using either FreeBSD jail or Solaris zones (new feature in upcoming solaris 10). The basic idea here is that you create a virtual environment within your master server, and the root user inside the virtual environment does not have any privileges outside. You could do this on any platform by setting up a chroot environment but chroot is less secure - there are ways to break out of a chroot if you can write files into it. jail and zones provide a more secure virtual environment. Note that people often refer to chroot environments as "jails" - these are NOT the same thing as the freebsd jail. there are two linux projects, "user-mode linux" which runs an entire linux kernel as a process under another linux, and "linux-vserver", which tries to do what freebsd jail does. Neither one of them appears to be fully baked, however. I spent quite a bit of time on uml before giving up because it just didn't seem stable. I didn't actually run linux-vserver but it looks to be under active development, and i was concerned it just wasn't ready for prime time. Note that "linux-vserver" and "linux virtual server" are not the same thing - linux virtual server is more of a clustering thing that allows multiple physical machines to act as one logical machine. I haven't considered the key-pair issue. I have a small enough environment that it would be manageable. You could look into using kerberos instead of ssh keys - it essentially provides a key management infrastructure. However, it is much more heavyweight than creating a bunch of keys. On Tue, Jun 15, 2004 at 03:37:21PM +0100, ww m-pubsyssamba wrote: danno -- dan pritts danno@internet2.edu systems administrator 734/352-4953 office internet2 734/834-7224 mobile
On Tue, Jun 15, 2004 at 03:37:21PM +0100, ww m-pubsyssamba wrote:> Hello list, > > I have a requirement to script a sync from a server to a UNIX workstation (Mac OS X) users desktop and profile related data at logon and > logoff. Rsync looks like it may be appropriate, but I am concerned about making a sufficiently secure connection between the server and the > client (given my sync must be non-interactive). > Rsh is not an option, so Ssh seems to be the only alternative. Now I'm quite familiar with Ssh, setting up public/private key pairs etc. but I'm > quite uncomfortable about using this across hundreds of workstations to provide the sync functionality I'm looking for. Specifically my fear is if > someone gains administrative access to their workstation and can access the ssh private key & ssh server key they will be able to access any > data they want from the central file server. Plus relying on keypairs is very messy from an administrative point of view. > I guess other people must have thought about a similar type of requirement in terms of security and was hoping I might get some pointers from > those how have done this before. My personal preference was to mount a share from the file server on the client and essentially do the sync all locally on the client but rsync doesn't seem to like doing this very much (apparently this is advised against),What doesn't rsync like? Do you mean something like a rsync between a local mount and a locally-mounted NFS export? That should be fine. -Chris> > any help gratefully recieved, thanks Andy. > -- > To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
My personal preference was to mount a share from the file server on the client and essentially do the sync all locally on the client but rsync doesn't seem to like doing this very much (apparently this is advised against), What doesn't rsync like? Do you mean something like a rsync between a local mount and a locally-mounted NFS export? That should be fine. -Chris>>Hi Chris, yes this is exactly what I mean. When I tested this it threw up lots of errors. A collegue of mine asked the question of MIT who developed the rsyncx version and they said: #This problem has been noted. The rsync developers recommend only local #mounts for rsyncs, or using the rsync network transports (or ssh) for #remote rsyncs. As of v1.7d, ssh is the fastest form of rsync to perform. If you think it should work ok, then I'll test it again, thanks for your comments, Andy. <<