Simple, when performing various git annex command over ssh, in particular a multi-file get, and using password authentication, git annex will prompt more than once for a user password. This makes batch updates very inconvenient.
I'd suggest using ssh-agent, or a passwordless ssh key. Possibly in combination with git-annex-shell if you want to lock down a particular ssh key to only being able to use git-annex and git-daemon.
Combining multiple operations into a single ssh is on the todo list, but very far down it. --Joey
OTOH, automatically running ssh in ControlMaster mode (and stopping it at exit) would be useful and not hard thing for git-annex to do.
It'd just need to set the appropriate config options, setting ControlPath to a per-remote socket location that includes git-annex's pid. Then at shutdown, run
ssh -O exit
on each such socket.Complicated slightly by not doing this if the user has already set up more broad ssh connection caching.
done! --Joey
Slightly more elaborate design for using ssh connection caching:
- Per-uuid ssh socket in
.git/annex/ssh/user@host.socket
- Can be shared amoung concurrent git-annex processes as well as ssh invocations inside the current git-annex.
- Also a lock file,
.git/annex/ssh/user@host.lock
. Open and take shared lock before running ssh; store lock in lock pool. (Not locking socket directly, because ssh might want to.) - Run ssh like:
ssh -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes user@host
- At shutdown, enumerate all existing sockets, and on each:
- Drop any shared lock.
- Attempt to take an exclusive lock (non-blocking).
ssh -q -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes -O stop user@host
(Will exit nonzero if ssh is not running on that socket.)- And then remove the socket and the lock file.
- Do same at startup. Why? In case an old git-annex was interrupted and left behind a ssh. May have moved to a different network in the meantime, etc, and be stalled waiting for a response from the network, or talking to the wrong interface or something. (Ie, the reason why I don't use ssh connection caching by default.)
- User should be able to override this, to use their own preferred
connection caching setup.
annex.sshcaching=false
Unless you are forced to use a password, you should really be using a ssh key.