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).
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.
```bash
git annex add mylargefile.bin
```
I was unable to automatically sync it using
```bash
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?
`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?
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.
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.
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.
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.
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.
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.
I was unable to automatically sync it using
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 rangin 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
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:
It's setting two keys in the ssh command,
diskstationback.key
andlocalserver.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:
GIT_SSH_COMMAND=ssh ...
like seen in the log, but also add-vvv
, soexport 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"
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.