Is it possible to force actions/checkout to use SSH rather than HTTPS?

[zaikunzhang]

Select Topic Area

Question

Body

Is it possible to force actions/checkout to use SSH rather than HTTPS?

Some of my actions on self-hosted runners encounter mistakes like

unable to access 'https://github.com/equipez/prima/': Empty reply from server

The repository is here: repo
The workflow can be found here: workflow
The detailed error log is here: error.log

According to https://stackoverflow.com/questions/27087483/how-to-resolve-git-pull-fatal-unable-to-access-https-github-com-empty , one of the solutions is to use SSH instead of HTTPS when checking out the repo (unless we want to use a proxy, which we do not).

The question is, how to force actions/checkout to use SSH? It seems to be using HTTPS according to the error log above.

Thanks.

[Anmol-Baranwal]

Yes, it is possible to force actions/checkout to use SSH rather than HTTPS. You can specify the ssh-key input parameter to actions/checkout, which will use the specified private key for authentication with GitHub. Here's an example of how to use it:

e.g. a sample code

- name: Checkout code
  uses: actions/checkout@v2
  with:
    repository: my-org/my-repo
    ssh-key: ${{ secrets.SSH_PRIVATE_KEY }}

---

There doesn't seem to be anything inherently wrong with this workflow, but here are a few observations:

1. The pull_request trigger is commented out with a warning that it must be disabled for self-hosted runners. It's good to see that you are aware of the potential dangers of running untrusted code on a self-hosted runner.

2. The schedule trigger is set to run the workflow every other day at noon UTC. This seems like a reasonable choice for a periodic test, but you should ensure that this frequency aligns with their specific testing needs.

3. The strategy section is defining a matrix of test parameters, which is a good practice for running tests with multiple combinations of inputs. However, you should consider whether the number of possible combinations is feasible for their available resources and testing time.

4. The steps section contains several shell commands that run various tests and linters. It's difficult to evaluate whether these are appropriate without more context about the project, but it's good to see that you are performing some level of automated testing and linting.

5. The upload-artifact step is saving log files as artifacts, which is a good way to capture the output of the tests for later review. However, you should consider whether these log files contain sensitive information and whether they should be encrypted or otherwise protected.

6. The final rm command is removing test data, which is generally a good practice to keep the runner environment clean. However, you should ensure that they're not deleting anything important or that might be needed by other steps in the workflow.

[zaikunzhang]

Thank you @Anmol-Baranwal for the response and detailed suggestions. I will try it.

[zaikunzhang]

Hi @Anmol-Baranwal ! Sorry to bother you with another question.

Is this workflow correct regarding the use of ssh key? workflow

When running, it failed with git@github.com: Permission denied (publickey).

Note that this flow is running on GitHub-hosted runners. Workflows on self-hosted runners do run correctly after adding ssh key as you said, for example, this workflow: workflow.

Did I overlook something? Many thanks.

[zaikunzhang]

Thank you @Anmol-Baranwal !

[airtower-luna]

Did you add that key to an account with permission to access the relevant repositories?

[zaikunzhang]

Did you add that key to an account with permission to access the relevant repositories?

I added both the public key and private key to https://github.com/libprima/prima , the former as a deploy key, the latter as an actions secret.

The configuration is basically the same as this workflow, which works well on a self-hosted runner.

Thank you.

[Anmol-Baranwal]

You should check these resources: (these might resolve your issue)

• https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port
• Gist

---

It seems like the workflow is attempting to use SSH to authenticate with GitHub when checking out the repository, but it's encountering an error because the SSH key is not set up correctly. Specifically, the error message git@github.com: Permission denied (publickey) suggests that the SSH key is either invalid or not authorized to access the repository.

To fix this, you will need to ensure that the SSH key used by the workflow is set up correctly and has the necessary permissions to access the repository. Few things, you should check

1. Check that the SSH key is correct: Verify that the SSH private key stored in the GitHub secret SSH_PRIVATE_KEY_ACT is correct and matches the public key added to the GitHub repository. You can do this by comparing the private key with the corresponding public key on your local machine.

2. Check that the SSH key has the necessary permissions: Verify that the SSH key has been added to your GitHub account and has the necessary permissions to access the repository. You can check this by going to your GitHub account settings and checking the SSH keys section.

3. Check that the repository is accessible via SSH: Verify that the repository is accessible via SSH by running ssh -T git@github.com on your local machine. If this command fails, it may indicate that there is a problem with your SSH key or with your GitHub account settings.

[Anmol-Baranwal]

@zaikunzhang
I just wanted to check in and see if you have any remaining questions or concerns about my answer. If not, would you please mark my response as accepted?

It would be greatly appreciated and it will also help other users who might be looking for a solution to a similar issue.

[zaikunzhang]

Hi @Anmol-Baranwal , your answer was indeed very helpful. However, I have not figured out how to make things work on GitHub-hosted runners yet.

Here is a minimal working example:

https://github.com/equipez/testkey

Workflow file:

https://github.com/equipez/testkey/blob/main/.github/workflows/test.yml

A run with failure on ubuntu-latest and success on self-hosted (I hope you have access to the detailed log):

https://github.com/equipez/testkey/actions/runs/4453061443/jobs/7821274009

You might like to have a look at it?

Thanks.

Best regards,
Zaikun

[zaikunzhang]

Finally, it works.

For the record, this is what I did.

To use an RSA key:

• Generate a new SSH key pair with ssh-keygen -t rsa -b 4096 -C "{email}".
• Copy your public key from .ssh/id_rsa.pub.
• Go to your repository settings and click Deploy Keys.
• Click Add deploy key and provide a title and your public key.
• Select Allow write access if you want this key to have write access to the repository.
• Copy your private key from .ssh/id_rsa.
• Go to your repository settings and click Secrets.
• Click New repository secret and provide a name and your private key.

To use an Ed25519 key:

• Generate a new SSH key pair with ssh-keygen -t ed25519 -C "{email}".
• Copy your public key from .ssh/id_ed25519.pub.
• Go to your repository settings and click Deploy Keys.
• Click Add deploy key and provide a title and your public key.
• Select Allow write access if you want this key to have write access to the repository.
• Copy your private key from .ssh/id_ed25519.
• Go to your repository settings and click Secrets.
  -Click New repository secret and provide a name and your private key.

[metaclips]

Also, you shouldn't use a password to generate your SSH else it won't work on CI actions/checkout

[deGennesMarc]

Follow up question on this : my git repo A need to access two other projects B and C.
I deployed an ssh key in B and C, and added the private keys to the secrets, but cannot figure how to make it work . Just listing the two keys won t work