rsync with and without ssh

if you're not prompted for a password, you should be okay. rsync is using your public key.

if you're suspicious, you can specify "-e ssh" in your rsync command to ensure it's using ssh.

use tcpdump for packet sniffing. if you need more, there are a number of tools out there, like ethereal (or whatever it's called these days).

here's a quote from rsync's man page:

"For remote transfers, a modern rsync uses ssh for its communications, but it may have been configured to use a different remote shell by default, such as rsh or remsh."

so it uses ssh by default. it won't if you set the remote shell to something else.


macbook pro 2.16 ghz, powerbook G4 1ghz, G4 400 mhz, poweredge and some junkers Mac OS X (10.4.9)

Question:

Backing up File-Vaulted Home directory with rsync & ssh & doing it all via cron jobbed script:



I've got rsync up and running fine.

I then created and distributed the necessary RSA keys, and this works fine from my limited privilege account called "backup". (as long as filevault is not involved)...

There is an issue with Rsync with SSH and filevault:

1) The target account is named "jeff" (this needs to be backed up)

2) The target directory (/Users/jeff/) is a filevault folder (encrypted sparse image which has been mounted as /Users/jeff/) - the user is jeff, group is jeff and permissions are user=rwx, group=(nothing?), everyone=(nothing)

3) Consequently, I planned to add user "backup" to group "jeff" and then run "chmod g+r /Users/jeff/"

4) Even as root, I cannot chmod /Users/jeff/ (operation not permitted) - I think this may have to do with either:

a) Immutability (either system or user) (I'm looking for the procedure to drop into single-user-only mode and change this immutability temporarily so that I can at least drop a ~/.ssh directory in place with some known keys)

b) Some factor unknown to me (but related to FileVault)(this gets into the sensitive area of "Where are the keys needed to get access to the sparse image, and how can I give my script access to those keys")

5) I then tried to run the backup as user "jeff", but I couldn't set up the authorized_keys file because I could not "/Users/jeff/ mkdir .ssh"(either as user "jeff" or user "root"). I think this too may be because of point #4a.

How should I correct this?


I've developed 2 work-around's (both of which functionally compromise or eliminate the value of filevault):

1)
a) Use my user "jeff" to rsync the /Users/jeff/ directory to a different location on the same machine.
b) Swizzle permissions such that I can run a second rsync script against this backup with user "backup" and send the data to a far-side machine.

2) Similar to above, but we move the iTunes library and hit the live copy with rsync: Move the iTunes & iPhoto & etc. over to a different directory (or for performance reasons a different drive) - utilize them by using the little publicized and demi-supported "hold control during application start to choose a library" capability. - Swizzle permissions such that user "backup" is able to pull backups from there and rsync them to a far-side machine.



I'd really like to set this up properly (leave the files in the filevault and back up directly from them), but I'll fall back to the work-around's if this is not feasible.

Thank you,

Jeff


PowerMac G5 dual 2.5, dual 2.0, Powermac G4 Mac OS X (10.4.8)

PowerMac G5 dual 2.5&2.0, Powermac G4 Mac OS X (10.4.8)

jeff, i haven't attempted your scenario yet, but i imagine it's possible without too much trickery. rather, i hope it is…

have you looked into using the security command to access/unlock your keychain? do filevault keys have corresponding keychain entries? does that even make sense?

hmmm…