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.
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
```
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>
execSync just started a second ssh-agent. `['-k']` argument was
treated as options, it didn't have `stdio` set, so stdio was piped and
returned (and ignored).
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.
