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.
Added support for GitHub Enterprise servers by loosening the
restrictions on the hostname portion of the deploy key comment being
"github.com" to any hostname and then using that hostname in the rest of
the config. Adjusted the regex to match the end of the line since the
comment portion is at the end. fixes#934
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>
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.
