We need to fix the SSH keys shipped with this action:
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/
But, we have another issue
(https://github.com/webfactory/ssh-agent/pull/108) with regards to host
keys: On self-hosted runners which are not ephemeral the known_host file
fills up with repeated entries, because every action run adds a new line
with the same host keys.
Also, on those machines, the old key will still be in the `known_hosts`
file.
IMHO this action should not be repsonsible for shipping SSH host keys,
that's too much responsibility.
This section in the code is a leftover from early days when GitHub
provided runners did not include SSH keys at all. For a long time
already, GH takes care of placing their SSH keys in their runner images.
For self-hosted runners, those people setting up the runner should fetch
and verify SSH keys themselves and put it into the `known_hosts` file.
I know this is a breaking change and is going to annoy users. But on the
other hand, there is no better opportunity to drop this feature than
with an emergency-style key revocation as today.
Closes#106, closes#129, closes#169, closes#170, closes#172.
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 change avoids the
`Comment for (public) key '' does not match GitHub URL pattern. Not treating it as a GitHub deploy key.`
log message that was caused by inappropriate parsing of `ssh-add -L` output and confused a lot of users already.
### Problem:
Observed error on `windows-2022` ([GitHub-hosted runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)) that `git` command cannot be found.
### Issue:
Cannot find git executable on on windows-2022 (GitHub-hosted runner) #136
### Solution:
This path improvement makes use of existing `path.js` to resolve and return correct `git.exe` path for Windows, leaving the executable name as it was for other operating systems.
### Caveats:
No idea how and why this `c://progra~1//git//usr//bin//git.exe` mumbo-jumbo works but it apparently did for other executables so figured it should work for `git.exe` (and it does).
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>
We need to fix the SSH keys shipped with this action:
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/
But, we have another issue
(https://github.com/webfactory/ssh-agent/pull/108) with regards to host
keys: On self-hosted runners which are not ephemeral the known_host file
fills up with repeated entries, because every action run adds a new line
with the same host keys.
Also, on those machines, the old key will still be in the `known_hosts`
file.
IMHO this action should not be repsonsible for shipping SSH host keys,
that's too much responsibility.
This section in the code is a leftover from early days when GitHub
provided runners did not include SSH keys at all. For a long time
already, GH takes care of placing their SSH keys in their runner images.
For self-hosted runners, those people setting up the runner should fetch
and verify SSH keys themselves and put it into the `known_hosts` file.
I know this is a breaking change and is going to annoy users. But on the
other hand, there is no better opportunity to drop this feature than
with an emergency-style key revocation as today.
Closes#106, closes#129, closes#169, closes#170, closes#172.
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 change avoids the
`Comment for (public) key '' does not match GitHub URL pattern. Not treating it as a GitHub deploy key.`
log message that was caused by inappropriate parsing of `ssh-add -L` output and confused a lot of users already.
### Problem:
Observed error on `windows-2022` ([GitHub-hosted runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)) that `git` command cannot be found.
### Issue:
Cannot find git executable on on windows-2022 (GitHub-hosted runner) #136
### Solution:
This path improvement makes use of existing `path.js` to resolve and return correct `git.exe` path for Windows, leaving the executable name as it was for other operating systems.
### Caveats:
No idea how and why this `c://progra~1//git//usr//bin//git.exe` mumbo-jumbo works but it apparently did for other executables so figured it should work for `git.exe` (and it does).
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>
