Q: Disk image can mount from local terminal with "open" command but not via ssh

That second paragraph in my original post is a bit of a distraction. The issue is not with AFP, that part works fine. The issue is with mounting the disk image with "open backup_image.sparsebundle". The DiskImageMounter.app launches as a result of that command whether I'm on a terminal session on the actual machine or secure shell. The difference is in a local session the disk image mounts but from a ssh session, it does not.

I verified this without actually being remote just now. If I open a terminal session and then "ssh localhost" and secure shell in to my own machine and try to open the disk image, it fails in the same manner. DiskImageMounter.app does not like being executed from a ssh session.

[user:~] user: who

computer_name console  Oct 18 00:17

computer_name ttys000  Oct 28 12:32       <---- ttys000 can open the disk image

[user:~] user: ssh localhost

Last login: Sun Oct 28 12:32:55 2012

[user:~] user: who

computer_name console  Oct 18 00:17

computer_name ttys000  Oct 28 12:32       <---- ttys000 can open the disk image

computer_name ttys001  Oct 28 12:33           (localhost)          <---- ttys001 can NOT open the disk image

computer_name ttys002  Oct 28 12:35        <---- ttys002 can open the disk image

I combed /private/var/log/eventmonitor and system.log but nothing appears (which is odd, system.log usually has too much info).

Great idea but there is a wrinkle in the plan. My disk images are password protected (encrypted). Using the "open" causes DiskImageMounter.app to launch and, since the password is stored in the keychain and always approved, I never have to enter the password so long as the image is mounted on the correct machine. I prefer that layer of security even though it is arguably flawed. If I open with hdiutil, it asks for the password and my script to synchronize goes from being automated to requiring interaction to enter the password. -stdinpass could work but then I'd have to store the password clear text in the script. I'll see if I can sort something out with -recover or "secuirty".

Odd that if I do "hdiutil attach backup_image.sparsebundle" on the local machine, it mounts without asking for the password but if I do it from a ssh session, it does ask.

The same goes with if I try to programatically get the password from the keychain with:

security find-generic-password -w -D "disk image password" -l backup_image.sparsebundle

If I'm local, it spits out the password, no problem. If I ssh in, no luck.

e.g.

security find-generic-password -w -D "disk image password" -l backup_image.sparsebundle | hdiutil attach backup_image.sparsebundle

This works locally just fine but again, hosed if I try it remotely

I suppose the solution is to store the password in they keychain of the computer trying to issue the remote command, programatically retreive it from that keychain in to a script variable and send it through the network?

Thanks for the idea though!

Doh.

Storing the password for the remote disk image in the local keychain of the computer running the script (in to a variable), then passing it accross to the remote machine worked. I'm not sure why all of this changed moving from Lion to Mountain Lion but I suppose it is slightly more secure.

To programatically mount and sync a remote encrypted disk:

#!/bin/bash

if [ -n "`mount | grep ~/sync`" ]; then

  echo "Already mounted"

else

  pw=$(security -v find-generic-password -w -D "application password")

  ssh -o ConnectTimeout=1 user@xxx.xxx.xxx.xxx "echo $pw | hdiutil attach /Users/user/backup_image.sparsebundle"

  mkdir ~/sync

  mount_afp -s "afp://matdup01:Armbwan1@192.168.1.102/Disk Image" ~/sync

fi

if [ $? -eq 0 ]; then

  echo "Mount succeeded!"

else

  echo "Mount Failed"

  exit 0

fi

rsync -vrxtu --delete-before --exclude _* "/Volumes/Media/new Media/" ~/sync/new\ media/

umount ~/sync

rmdir ~/sync

exit