I have taken a look at the issue board, and does not seem to be able find the issue address there.
I would like to be able to use the deploy keys feature of repository to allow some of our workflow to be automated. I understand this differs from personal ssh keys, as deploy keys, in principle, only allow read access to the affected repository, whereas ssh keys can be used to have read/write rights on all repositories.
My current attempt at adding a deploy key and git clone with the correct private key results in
GIN: Key Error
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
steps to reproduce
1/ create new ssh key on local machine with:
$ ssh-keygen -f ~/.ssh/tmp
2/ create a new private repo on g-node, optionally add some content
3/ save the deploy key cat ~/.ssh/tmp.pub to the private repo > settings > deploy keys > add deploy keys
4/ attempt to clone the repo with the newly created crendential
GIN: Key Error
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
Dear all,
I have taken a look at the issue board, and does not seem to be able find the issue address there.
I would like to be able to use the `deploy keys` feature of repository to allow some of our workflow to be automated. I understand this differs from personal `ssh keys`, as `deploy keys`, in principle, only allow read access to the affected repository, whereas `ssh keys` can be used to have read/write rights on all repositories.
My current attempt at adding a deploy key and `git clone` with the correct private key results in
```
GIN: Key Error
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
```
**steps to reproduce**
1/ create new ssh key on local machine with:
```bash
$ ssh-keygen -f ~/.ssh/tmp
```
2/ create a new private repo on g-node, optionally add some content
3/ save the deploy key `cat ~/.ssh/tmp.pub` to the `private repo` > `settings` > `deploy keys` > `add deploy keys`
4/ attempt to clone the repo with the newly created crendential
```bash
$ # <https://stackoverflow.com/a/4565746/6059235>
$ ssh-agent bash -c 'ssh-add ~/.ssh/tmp; git clone git@gin.g-node.org:/your_username/new_dataset_name.git'
```
**expected behaviour**
clones repo
**actual behaviour**
```
GIN: Key Error
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
```
I've pinpointed the cause of the issue and this is a bug in GIN that was introduced with some changes made a while ago. The fix is rather straightforward, but I need to make sure it wont introduce any other issues, so it might take a while to test before deploying the fix.
In the meantime, I'd like to offer a workaround for your use case: You could create a user for your automated deployments, set a public SSH key for that user and add them as a read-only collaborator to the repository. I hope this isn't a big inconvenience.
Please don't close this issue. I'd like to keep it open so I can update it and close it when the fix is deployed. It will also be visible to anyone who might have the same issue before it's fixed.
Thank you for reporting this.
Hi again Xiao.
I've pinpointed the cause of the issue and this is a bug in GIN that was introduced with some changes made a while ago. The fix is rather straightforward, but I need to make sure it wont introduce any other issues, so it might take a while to test before deploying the fix.
In the meantime, I'd like to offer a workaround for your use case: You could create a user for your automated deployments, set a public SSH key for that user and add them as a read-only collaborator to the repository. I hope this isn't a big inconvenience.
Please don't close this issue. I'd like to keep it open so I can update it and close it when the fix is deployed. It will also be visible to anyone who might have the same issue before it's fixed.
Thank you for reporting this.
Thanks for the clarification and the quick response.
I believe in the meantime, I can just create a personal SSH key. The automated pipeline we are running should be secure.
I will leave this issue open, also to remind myself to swap the SSH keys when the issue is resolved.
Kind regards,
Xiao
Dear Achilleas,
Thanks for the clarification and the quick response.
I believe in the meantime, I can just create a personal SSH key. The automated pipeline we are running should be secure.
I will leave this issue open, also to remind myself to swap the SSH keys when the issue is resolved.
Kind regards,
Xiao
Dear all,
I have taken a look at the issue board, and does not seem to be able find the issue address there.
I would like to be able to use the
deploy keysfeature of repository to allow some of our workflow to be automated. I understand this differs from personalssh keys, asdeploy keys, in principle, only allow read access to the affected repository, whereasssh keyscan be used to have read/write rights on all repositories.My current attempt at adding a deploy key and
git clonewith the correct private key results insteps to reproduce
1/ create new ssh key on local machine with:
2/ create a new private repo on g-node, optionally add some content
3/ save the deploy key
cat ~/.ssh/tmp.pubto theprivate repo>settings>deploy keys>add deploy keys4/ attempt to clone the repo with the newly created crendential
expected behaviour
clones repo
actual behaviour
Hello Xiao. I see the same issue. Let me look into it and get back to you.
Hi again Xiao.
I've pinpointed the cause of the issue and this is a bug in GIN that was introduced with some changes made a while ago. The fix is rather straightforward, but I need to make sure it wont introduce any other issues, so it might take a while to test before deploying the fix.
In the meantime, I'd like to offer a workaround for your use case: You could create a user for your automated deployments, set a public SSH key for that user and add them as a read-only collaborator to the repository. I hope this isn't a big inconvenience.
Please don't close this issue. I'd like to keep it open so I can update it and close it when the fix is deployed. It will also be visible to anyone who might have the same issue before it's fixed.
Thank you for reporting this.
Dear Achilleas,
Thanks for the clarification and the quick response.
I believe in the meantime, I can just create a personal SSH key. The automated pipeline we are running should be secure.
I will leave this issue open, also to remind myself to swap the SSH keys when the issue is resolved.
Kind regards,
Xiao