#70 Separate ssh key necessary for using git-annex?

This is probably more of a clarification on how to use git-annex directly. If I manually add a file under a gin repository using git-annex, i.e.

git annex add mylargefile.bin

I was unable to automatically sync it using

gin upload .

After some digging, it seems that the ssh-keys that gin manages under the hood are not forwarded to the underlying git-annex call. Only after explicitly adding new keys using ssh-keygen and then adding those to my ssh-agent did I manage to upload the files.

I should note that this is using a private G-node instance running in Docker on my local computer (purely for testing purposes).

gin upload will (or should) use the ssh keys that were generated when you ran gin login for your particular server. If you look at the log file, do you see if it's trying to use the key or not?

Yes, it looks like it's trying to use the appropriate key. Here are the relevant lines from the log

2024/07/17 07:52:31 env GIT_SSH_COMMAND=ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes -o 'UserKnownHostsFile="/Users/roger/Library/Application Support/g-node/gin/known_hosts"'
2024/07/17 07:52:31 Running shell command (Dir: /Volumes/Drive1/data/MyTestData): git annex sync --verbose --no-pull --no-commit origin
2024/07/17 07:52:31 env GIT_SSH_COMMAND=ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes -o 'UserKnownHostsFile="/Users/roger/Library/Application Support/g-node/gin/known_hosts"'
2024/07/17 07:52:31 Running shell command (Dir: /Volumes/Drive1/data/MyTestData): git annex whereis --json .
2024/07/17 07:52:31 env GIT_SSH_COMMAND=ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes -o 'UserKnownHostsFile="/Users/roger/Library/Application Support/g-node/gin/known_hosts"'
2024/07/17 07:52:31 Running shell command (Dir: /Volumes/Drive1/data/MyTestData): git annex copy --json-progress --to=origin .
2024/07/17 07:52:32 Error during AnnexPush
2024/07/17 07:52:32
2024/07/17 07:52:32 The following error occured:
2024/07/17 07:52:32 Exiting with ERROR message: 1 operation failed

If I manually add the diskstationback.key key to the ssh agent, I can upload the file using git annex.

I have an idea of what might be wrong:

env GIT_SSH_COMMAND=ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key ...

It's setting two keys in the ssh command, diskstationback.key and localserver.key. This should work fine in most cases but it will fail if both keys are configured on the same server but for different users. In that case, it will depend on which key is used first and if that user who owns the key has permission to write to the repository.

Are those two keys for the same server?

This is really an oversight in the gin client. It should only be using the key for the specific server and user.

Hm, they are actually for two different servers. Is it possible that specifying two different keys confuses ssh somehow?

Possibly. We can debug the thing by replicating what gin-cli does:

• Set the GIT_SSH_COMMAND=ssh ... like seen in the log, but also add -vvv, so export GIT_SSH_COMMAND="ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key -o IdentitiesOnly=yes"
• Run the git-annex command that failed: git annex copy --json-progress --to=origin .

The verbose output will show which key it tried and why it failed. You can then remove the wrong key from the GIT_SSH_COMMAND and try again to see if it works.

Hm, this is weird. According to the output, it is not even trying to use the key I specify in the -i argument. I think that suggests there is something wrong with my ssh config somehow. I'll have to do some investigations.