[core22] "sudo snapcraft --bind-ssh" known_hosts access issue

snapcraft
1

Hi,

To say shortly when running locally (on the host) with (only flag) "sudo snapcraft --destructive-mode" I’m having no problem with the build (at least in part of cloning private repo via ssh , however without "--destructive-mode" It does not go.

Main issue that I’m encountering with during the build:

The authenticity of host 'gitlab.com (172.65.251.78)' can't be established.                                                                                        
ED25519 key fingerprint is SHA256:eUXGGm1YGsMAS7vkcx6JOJdOGHPe005Qp4taiCfCLB8.
This key is not known by any other names

I’ve tried to run it with "--bind-ssh" option and I’m still encountering the same issue, but within the logs I see some new extra lines:

Executing: git clone --recursive --branch v0.17.1d git@gitlab.com:PORTL/<blahblarepo>.git
Cloning into '/root/parts/<blahblarepo>/src'...
hostkeys_find_by_key_hostfile: hostkeys_foreach failed for /root/.ssh/known_hosts: Permission denied

So how can I run my build without destructive mode in order to obtain clean build

2

If you run that command manually, what do you get? Do you need to accept the keys?

Then if I understand correctly, you’re looking for a way to spawn a clean build instance, an lxc container or a multipass vm, but which will have the private repo keys already included?

3

Thank you for the answer. When I’m manually running git clone --recursive --branch v0.17.1d git@gitlab.com:PORTL/<blahblarepo>.git

I have no problems at all - repo is cloned without any of my further actions required (there’s no any kind of yes/no confirmation required needed). And was successfully cloned for both root user (with added "sudo") and from within my own (non-sudo) user. I’ve cared that SSH keys were added to my gitlab repo from both root and non-root users.

And your assumption is right. I simply need my part to be cloned within the snapcarft process. Again - I don’t have any problems when I run it with "--destruction-mode". But If I do without it and with addition of "--bind-ssh" neither of those do a job. Looks like an issue? Or what is wrong with that. The part which I’m talking about in my snapcraft yaml file looks like that:

    parts:
      blah-blah-part:
        after: [ whateverpart ]
        source: git@gitlab.com:PORTL/<blah-blah-private-repo>.git
        source-type: git
        source-tag: v0.1
        plugin: nil
        stage-packages:
          - dmidecode
          - curl
        override-build: |
          if [ ! -f $CRAFT_PART_INSTALL/bin/node ]; then
            tar xzf /root/node-v14.16.1-linux-x64.tar.gz -C $CRAFT_PART_INSTALL/ --no-same-owner --strip-components=1
          fi

          npm config set unsafe-perm true
          npm install
          npm run build
          mkdir -p $CRAFT_PART_INSTALL/lib/node_modules/blah-blah-private-repo/dist
          cp -r * $CRAFT_PART_INSTALL/lib/node_modules/blah-blah-private-repo/
          cp .env.example $CRAFT_PART_INSTALL/server_dot_env_example
4

Have you considered, as a workflow:

  • Start an lxc container manually.
  • Configure it as a build environment with snapcraft.
  • Push the ssh keys into the container.
  • Send the build job into the container (either interactively or via lxc-exec.

This way, you can script the whole thing.

5

I’m sorry but that look like some kind of workarounds, so thank you but I’m not considering any workarounds like a real solution … Actually as workaround I can simply use “–destructive-mode” what I do, howver it doesn’t work perfect for the pureness of snap build process. What’s about “–bind-ssh” ? Why doesn’t it work? … is it some kind of bug? Would you fix it?

6

I am merely trying to give you a solution that could work potentially, both in terms of interactive work as well as something that can be scripted or automated. Not sure about the --bind-ssh option, and if there’s a bug there. Can you submit one against snapcraft on GH, so the devs can take a look?

Thanks!

7

ok, if there are no other option - thank you

8

This could be a permissions issue, if you ran sudo snapcraft --destructive-mode in the past you might need to fix the permissions of the host file. This should generally work I believe.