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:
    1. Drop any shared lock.
    2. Attempt to take an exclusive lock (non-blocking).
    3. 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.)
    4. 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.

ssh-keygen
#put local .ssh/id_?sa.pub into remote .ssh/authorized_keys (which needs to be chmod 600)
ssh-add
git annex whatever
Comments on this page are closed.