## TL;DR;
Multiple deploy keys in docker doesn't work after following everything in README. Loading `.gitconfig` into git in docker fixed it.
## Summary
We are using multiple Github deploy keys in docker for PIP to install dependencies from multiple private Github repositories. However, after doing everything from the webfactory/ssh-agent README, including adding comment when generating keys and copying `.gitconfig` and `.ssh/` into docker, the multiple deploy keys still didn't work. We print out the verbose log for `git ssh` when doing PIP install by using `RUN --mount=type=ssh GIT_SSH_COMMAND="ssh -v" pip install -r /requirements.txt`. Turns out that it was blindly accepting the first key (repo-a) even though it should use the second key (repo-b) which is way it couldn't fetch from the repo-b. After some research, the webfactory/ssh-agent depends on the customized `.gitconfig` file to map the correct ssh key to the correct repository link. Then we did a `RUN git config -l` in the Dockerfile and the output was empty which means that although we are copying the `.gitconfig` file into the docker image, it was not loaded into git config. So after adding `RUN mv /root/.gitconfig /etc/gitconfig` into the Dockerfile, the PIP install started working. In conclusion, the `.gitconfig` config file doesn't do anything sitting in the `/root` folder.
### Following was the original error message excluding sensitive information that helped us figure out the root cause:
```
#24 3.926 debug1: Will attempt key: git@github.com:owner/repo-a.git ED25519 SHA256:*** agent
#24 3.927 debug1: Will attempt key: git@github.com:owner/repo-b.git ED25519 SHA256:*** agent
...
#24 4.013 debug1: Authentications that can continue: publickey
#24 4.014 debug1: Next authentication method: publickey
#24 4.014 debug1: Offering public key: git@github.com:owner/repo-a.git ED25519 SHA256:*** agent
#24 4.047 debug1: Server accepts key: git@github.com:owner/repo-a.git ED25519 SHA256:*** agent
#24 4.076 debug1: Authentication succeeded (publickey).
#24 4.077 Authenticated to github.com ([140.82.112.3]:22).
#24 4.078 debug1: channel 0: new [client-session]
#24 4.079 debug1: Entering interactive session.
#24 4.079 debug1: pledge: network
#24 4.099 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
#24 4.143 debug1: Sending environment.
#24 4.144 debug1: Sending env GIT_PROTOCOL = version=2
#24 4.145 debug1: Sending env LANG = C.UTF-8
#24 4.146 debug1: Sending command: git-upload-pack '/owner/repo-b.git'
#24 4.207 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
#24 4.207 ERROR: Repository not found.
```
### Following was the log of successfully using multiple deploy keys in docker:
```
#28 5.568 debug1: Will attempt key: /root/.ssh/key-*** (repo-b) ED25519 SHA256:*** explicit agent
...
#28 5.722 debug1: Authentications that can continue: publickey
#28 5.722 debug1: Next authentication method: publickey
#28 5.722 debug1: Offering public key: /root/.ssh/key-*** (repo-b) ED25519 SHA256:*** explicit agent
#28 5.786 debug1: Server accepts key: /root/.ssh/key-*** (repo-b) ED25519 SHA256:*** explicit agent
#28 5.846 debug1: Authentication succeeded (publickey).
#28 5.846 Authenticated to github.com ([140.82.113.4]:22).
#28 5.847 debug1: channel 0: new [client-session]
#28 5.847 debug1: Entering interactive session.
#28 5.848 debug1: pledge: network
#28 5.848 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
#28 5.901 debug1: Sending environment.
#28 5.901 debug1: Sending env GIT_PROTOCOL = version=2
#28 5.902 debug1: Sending env LANG = C.UTF-8
#28 5.902 debug1: Sending command: git-upload-pack 'owner/repo-b.git'
#28 6.414 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
#28 6.415 debug1: channel 0: free: client-session, nchannels 1
#28 6.416 debug1: fd 0 clearing O_NONBLOCK
#28 6.416 debug1: fd 2 clearing O_NONBLOCK
#28 6.417 Transferred: sent 12836, received 265192 bytes, in 0.6 seconds
#28 6.417 Bytes per second: sent 22608.0, received 467080.7
#28 6.418 debug1: Exit status 0
```
The current docs mention only `docker/build-push-action` in conjunction
with deploy keys.
This might mislead users to believe, that this only applies to said
Action. But the concept applies to all workflows that somehow use
`docker build` with deploy keys.
This PR clarifies the relevant section.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
On my self-hosted Windows runners, the `git`, `ssh-agent`, and `ssh-add`
commands are not located in the locations that are currently hard-coded
in `paths.js`.
With this PR, I am able to get this action to work on my runners as
follows:
```yaml
- uses: webfactory/ssh-agent@...
with:
ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
git-cmd: git
ssh-agent-cmd: ssh-agent
ssh-add-cmd: ssh-add
```
Update `actions/checkout` to `@v3` and make it syntactically correct in order to allow copy and paste.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
This commit adds the new `log-public-key` action input.
Closes#122 (contains the suggested changes plus a few tweaks and documentation), fixes#100.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
This change adds some extra clarification to the documentation to show how to setup the `docker/build-push-action` step with this action. This is very helpful when using buildkit's `RUN --mount=type=ssh`. We found this to be a little confusing and the GH issues we found on the matter didn't help!
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
* Add note about using cargo with private dependencies
* Update doc to mention Windows only
* Add alternative workaround
* Create extra main section for tips and information regarding different languages/tools
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
Thanks to @thommyhh for this contribution!
Unless the `SSH_AUTH_SOCK` is configured explicitly, this change will make the SSH agent use a random file name for the socket. That way, multiple, concurrent SSH agents can be used on non-ephemeral, self-hosted runners.
A new post-action step will automatically clean up the running agent at the end of a job.
Be aware of the possible security implications: Two jobs running on the same runner might be able to access each other's socket and thus access repositories and/or hosts.
