act
act copied to clipboard
Incorrect GitHub SSH keys (or missing new ones)
Bug report info
15:25:30 ~/Repositories/Personal/template-core main $ act --bug-report
act version: 0.2.52
GOOS: darwin
GOARCH: arm64
NumCPU: 8
Docker host: DOCKER_HOST environment variable is not set
Sockets found:
/var/run/docker.sock
$HOME/.docker/run/docker.sock
Config files:
/Users/andrew/.actrc:
-P ubuntu-latest=catthehacker/ubuntu:act-latest
-P ubuntu-22.04=catthehacker/ubuntu:act-22.04
-P ubuntu-20.04=catthehacker/ubuntu:act-20.04
-P ubuntu-18.04=catthehacker/ubuntu:act-18.04
Build info:
Go version: go1.21.1
Module path: command-line-arguments
Main version:
Main path:
Main checksum:
Build settings:
-buildmode: exe
-compiler: gc
-ldflags: -X main.version=0.2.52
DefaultGODEBUG: panicnil=1
CGO_ENABLED: 1
CGO_CFLAGS:
CGO_CPPFLAGS:
CGO_CXXFLAGS:
CGO_LDFLAGS:
GOARCH: arm64
GOOS: darwin
Docker Engine:
Engine version: 23.0.5
Engine runtime: runc
Cgroup version: 2
Cgroup driver: cgroupfs
Storage driver: overlay2
Registry URI: https://index.docker.io/v1/
OS: Docker Desktop
OS type: linux
OS version:
OS arch: aarch64
OS kernel: 5.15.49-linuxkit
OS CPU: 4
OS memory: 7951 MB
Security options:
name=seccomp,profile=builtin
name=cgroupns
Command used with act
Anything.
Describe issue
Most of my problem information is at https://github.com/nektos/act/discussions/2035
But generally, I'm getting this error when running act locally:
The authenticity of host 'github.com (140.82.112.3)' can't be established.
| ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
| This key is not known by any other names.
I used Docker to enter the machine and check the available keys:
docker exec -it act-MegaLinter-MegaLinte... /bin/bash
When I entered, I noticed there was no user SSH key, so I checked the global one:
cat /etc/.ssh/ssh_known_hosts
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
ssh.dev.azure.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7Hr1oTWqNqOlzGJOfGJ4NakVyIzf1rXYd4d7wo6jBlkLvCA4odBlL0mDUyZ0/QUfTTqeu+tm22gOsv+VrVTMk6vwRU75gY/y9ut5Mb3bR5BV58dKXyq9A9UeB5Cakehn5Zgm6x1mKoVyf+FFn26iYqXJRgzIZZcZ5V6hrE0Qg39kZm4az48o0AUbf6Sp4SLdvnuMa2sVNwHBboS7EJkm57XQPVU3/QpyNLHbWDdzwtrlS+ez30S3AdYhLKEOxAG8weOnyrtLJAUen9mTkol8oII1edf7mWWbWVf0nBmly21+nZcmCTISQBtdcyPaEno7fFQMDD26/s0lfKob4Kw8H
Sure enough, the known hosts are missing a number of GitHub's more secure SSH key fingerprints, as published here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
It should look like this:
$ ssh-keyscan github.com
# github.com:22 SSH-2.0-babeld-dd067d10
github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
# github.com:22 SSH-2.0-babeld-dd067d10
# github.com:22 SSH-2.0-babeld-70f1bac9
github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
# github.com:22 SSH-2.0-babeld-dd067d10
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
# github.com:22 SSH-2.0-babeld-dd067d10
My system is configured to use ED25519, which is significantly more secure and becoming the standard encryption for keys moving forward for most systems. Not including the ED25519 key in the SSH keys for the container is going to cause more and more people to have issues.
I'm hoping this can be hotfixed, because I'm completely blocked until this can be fixed.
Link to GitHub repository
No response
Workflow content
N/A
Relevant log output
See above.
Additional information
No response
This may be an issue with https://github.com/oxsecurity/megalinter - I've opened the issue above to help dive in. I'm leaving this open in case someone wants to confirm.
So I've been running megalinter manually since opening this - no issues with them. That said, I can access GitHub via SSH
My best guess is this all lies in the fact that the Docker container purposely only pulls the RSA fingerprints from GitHub, which is deprectated, per https://github.com/catthehacker/docker_images/issues/115
My system is configured to use ED25519, which is significantly more secure and becoming the standard encryption for keys moving forward for most systems. Not including the ED25519 key in the SSH keys for the container is going to cause more and more people to have issues.
I'm hoping this can be hotfixed, because I'm completely blocked until this can be fixed.
Since you are the first one reporting this kind of issue and didn't gain any thumbs up, we have a sightly different opinion how important your problem is. I will merge your PR now.
act allows to use custom images and extending it with cached known hosts is only a two line dockerfile, so I'm kinda surprised this would be a blocking issue for you.
Thanks @ChristopherHX - honestly I'm not confident this is even my issue. I've just hit a wall with the tool as to how I can debug it further with the given images.
It's certainly a two-line Dockerfile... followed by a plethora of entrypoint logic, so unfortunately it's not that trivial.
Thought i'd give the issue its first thumbs up since i just tried to use act for the first time and i have been banging my head against a wall with my action for an entire day, found this tool to try to alleviate some of the time consuming process of testing the action, only to be faced with something ELSE to fix first. I agree that this is trivial but when you have been working all day with a headache like me, something like this cropping up just when you think you've found a tool that might help you, sad times ðŸ˜
Thought i'd give the issue its first thumbs up since i just tried to use act for the first time and i have been banging my head against a wall with my action for an entire day, found this tool to try to alleviate some of the time consuming process of testing the action, only to be faced with something ELSE to fix first. I agree that this is trivial but when you have been working all day with a headache like me, something like this cropping up just when you think you've found a tool that might help you, sad times ðŸ˜
Hah - I appreciate the affirmation. I mentioned in the original discussion, this is an issue that will become more prevelant as users start using the new standard GitHub switched to - thumbs up isn't always a great way to determine importance. It's not often people create new keys, but this is an issue that will certainly become more common as people rotate keys and new users come on board, and it completely blocks use of the tool. All it takes is one new member joining a team at a company and the tool is incompatible with GitHub for them.
Unfortunately for me, our Chief Architect raised their eyebrows at the response - we've had to strip act from our entire pipeline, as it was placed on our OSS blacklist. There was quite some surprise at the response and a loss of confidence the utility would continuously be maintained in a way we tied our training/infrastructure standards to. Too much risk of having to rip it out later, apparently.
a loss of confidence the utility would continuously be maintained in a way we tied our training/infrastructure standards to
I have also a loss of confidence, because PR reviews take too long in nektos/act.
Still wondering why act was hyped, it was even worse in compatibility at the time I found it so I decided to build my own tool to use actions/runner locally instead of act.
The only reason I contributed to act is, it works flawless on non standard OS/arch. In that context is compatibility with GitHub Hosted Runners less important.
BTW this was my own opinion
Since you are the first one reporting this kind of issue and didn't gain any thumbs up, we have a sightly different opinion how important your problem is.
If you look at https://github.com/actions/runner/issues/2009 you can even loose confidence in GitHub Actions, not even a single response within a year. That's how it works in GitHub.
Using webfactory/ssh-agent solved the issue for me.
With act version 0.2.57, the run stops and hangs in the step of validating GitHub SSH Host keys:
The authenticity of host 'github.com (140.82.121.4)' can't be established.
Getting a shell in the container that runs the Action, showcases that there is not known hosts setup for Github:
System
# ls -laR /etc/ssh/
/etc/ssh/:
total 16
drwxr-xr-x 3 root root 4096 Jan 31 23:24 .
drwxr-xr-x 48 root root 4096 Feb 7 09:05 ..
-rw-r--r-- 1 root root 1650 Dec 21 16:09 ssh_config
drwxr-xr-x 2 root root 4096 Dec 21 16:09 ssh_config.d
/etc/ssh/ssh_config.d:
total 8
drwxr-xr-x 2 root root 4096 Dec 21 16:09 .
drwxr-xr-x 3 root root 4096 Jan 31 23:24 ..
User
# ls -la ${HOME}/.ssh
total 20
drwxr-xr-x 2 root root 4096 Feb 7 09:05 .
drwx------ 4 root root 4096 Feb 7 09:05 ..
-rw-r--r-- 1 root root 460 Feb 7 09:05 config
-rw------- 1 root root 132 Feb 7 09:05 key-3a9c3d6391e0f4e1619bdffd1194e33d1b589fd1177bb0b9d26a0dbd3efe38d6
-rw------- 1 root root 609 Feb 7 09:05 key-c15940041a28ed9eef76aa49af2554baa458b51da38c5a23b654226cad012eca
Also testing GitHub SSH connection also stops and asks for host key acceptance:
# ssh -T [email protected]
The authenticity of host 'github.com (140.82.121.3)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
I use webfactory/[email protected] and it does not solve the issue as @VincentTanguayCasgrain mentioned.
What our Action does is that is adds SSH private keys of Github repos with webfactory/[email protected] and then use pip install for installing the private Github repo projects via a requirement of type git+ssh://[email protected]/REPO.git@BRANCH#egg=REPO
I have updated Node.js to 20.x in our Github Action container and still the known hosts are not setup properly by webfactory/ssh-agent. I have a workaround for people wishing to use Act for testing Github Actions, just add this step before any SSH related step:
# Setup GitHub known hosts
- name: GitHub SSH known hosts
shell: bash
run: mkdir -p ~/.ssh && ssh-keyscan github.com > ~/.ssh/known_hosts
UPDATE: It does not work when run by Github instead of Act locally:
Host key verification failed.
fatal: Could not read from remote repository.
I am starting to get the feeling there are major issues in general between Act, Github runners and Actions integration. The inconsistencies are too many to ignore.
UPDATE #2: It works in Github runner if you add the host keys to system file instead of user known_hosts:
# Setup GitHub known hosts
- name: GitHub SSH known hosts
shell: bash
run: |
ssh-keyscan github.com > /etc/ssh/ssh_known_hosts || exit 1
exit 0
Issue is stale and will be closed in 14 days unless there is new activity