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


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 (' 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

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?

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:

        after: [ whateverpart ]
        source: git@gitlab.com:PORTL/<blah-blah-private-repo>.git
        source-type: git
        source-tag: v0.1
        plugin: nil
          - 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

          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

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.

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?

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?


ok, if there are no other option - thank you

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.