Run inside a Docker container

[rieschl]

It took me forever to figure out, why this action doesn't work if I run the whole workflow inside a container.
The problem is that the Github Action somehow changes/sets the HOME variable inside the container so that the ~/.ssh/known_hosts file is at a wrong location.
This action puts the Github PubKeys inside ~/.ssh/known_hosts which is in the home path of the runner. But the running container normally runs as root so ssh looks for /root/.ssh/known_hosts which doesn't exist.
Copying the known_hosts to this location if the workflow is running inside Docker solves the problem. As I am a total Node noob I just played around with the dist/index.js file, but putting the following snippet after creating the known_hosts file the SSH agent also works inside docker:

    if(fs.existsSync('/.dockerenv') && child_process.execFileSync('id', ['-u']).toString().trim() === '0') {
        fs.mkdirSync('/root/.ssh', { recursive: true});
        fs.copyFileSync(`${homeSsh}/known_hosts`, '/root/.ssh/known_hosts');
    }

I'm not sure if that somehow breaks running the action in Windows because in Windows there is no id command. But that shouldn't be a problem because Github Actions currently doesn't allow running non-Linux containers. Also, I don't know if the root check is even necessary because probably all containers run as root.

Would it be possible to add this snippet to your action so Docker users can also use it? :)

[mpdude]

Does it work if we put the keys into /etc/ssh/known_hosts?

That should be the system (not user specific) file and we could get around all attempts to detect the user and/or HOME.

[mpdude]

Correction: That file might be /etc/ssh/ssh_known_hosts, we might need to check both.

[rieschl]

Right, it also works if I try /etc/ssh/ssh_known_hosts but we'd also have to check if the user is root or has write permission on that file.

[rieschl]

Hi Are there any updates on this? I'm about to roll out github actions to ~20 packages so it would be nice if I can skip the mkdir -p /root/.ssh; ssh-keyscan -t rsa github.com >> /root/.ssh/known_hosts part. Thanks!

[mpdude]

No progress, I’m afraid. This is open source, so we place the utmost reliance upon the zealous cooperation of the public.

If, however, you can provide a pull request, I’d be happy to review it!

What if we try to write to both known_hosts file locations, ignoring errors?

Would that solve it?

[quisse]

I am experiencing the same issue but not when running in a container.

name: Test
on:
  [push, pull_request]

jobs:
  build:

	name: Test ssh
	runs-on: ubuntu-latest

	steps:

	  - uses: webfactory/ssh-agent@v0.4.0
		with:
		  ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
	  - run: ssh-keyscan -t rsa github.com >> /etc/ssh/ssh_known_hosts
	  - run: ssh -T git@github.com

[epic0tix]

It took me forever to figure out, why this action doesn't work if I run the whole workflow inside a container.
The problem is that the Github Action somehow changes/sets the HOME variable inside the container so that the ~/.ssh/known_hosts file is at a wrong location.
This action puts the Github PubKeys inside ~/.ssh/known_hosts which is in the home path of the runner. But the running container normally runs as root so ssh looks for /root/.ssh/known_hosts which doesn't exist.
Copying the known_hosts to this location if the workflow is running inside Docker solves the problem. As I am a total Node noob I just played around with the dist/index.js file, but putting the following snippet after creating the known_hosts file the SSH agent also works inside docker:

    if(fs.existsSync('/.dockerenv') && child_process.execFileSync('id', ['-u']).toString().trim() === '0') {
        fs.mkdirSync('/root/.ssh', { recursive: true});
        fs.copyFileSync(`${homeSsh}/known_hosts`, '/root/.ssh/known_hosts');
    }

I'm not sure if that somehow breaks running the action in Windows because in Windows there is no id command. But that shouldn't be a problem because Github Actions currently doesn't allow running non-Linux containers. Also, I don't know if the root check is even necessary because probably all containers run as root.

Would it be possible to add this snippet to your action so Docker users can also use it? :)

I should have read this more carefully as I spent the same time trying to track this down one run after another 😄

[soltex1]

I am trying to use Packer:

uses: docker://hashicorp/packer:1.6.5

but it doesn't have access to the SSH keys.

Is there a way to achieve this?

[mpdude]

Thank you @rieschl for your suggestion and working on this, and thanks to @mwik for creating #58 for it!

The code change suggested in the opening comment here looks like some specialized edge case logic... I wonder if we could find a more general, cleaner way of dealing with this?

I understand that /etc/ssh/ssh_known_hosts might work inside a container, but not in the regular runner environment, since that file is probably read-only or could be changed only be the root user, but Actions use a dedicated runner UID.

So, what does HOME point to in the containerized action run? To my understanding, HOME is what the ~ resolves to, so why doesn't ssh pick up $HOME/.ssh/known_hosts?

[mpdude]

Oh, and does it make a difference inside the container when we're using os.homedir() instead of the HOME env var?