SSHPublicKey created too late for cd_content

[timeu]

Overview of the Issue

Similar to the issue in the vmware plugin (https://github.com/hashicorp/packer-plugin-vmware/issues/177) this is also happening with the QEMU plugin. The SSHPublicKey step runs after the creation of the CD/Floppy and thus cannot be used there.

Reproduction Steps

Add to the source definition

cd_content = {
    meta-data = "instance-id: \"ubuntu-${uuidv4()}\""
    user-data = <<-EOF
      #cloud-config
      manage_etc_hosts: localhost
      disable_root: false
      ssh_authorized_keys:
        - {{ .SSHPublicKey }}
      EOF
  }
  cd_label             = "cidata"

Plugin and Packer version

From packer version packer-plugin-qemu_v1.1.0_x5.0_linux_amd64

[lbajolet-hashicorp]

Hi @timeu,

I'd have to investigate, but if I had to guess, this doesn't look feasible as the builder's the one creating the ssh key, and the source configuration needs to be complete (i.e. interpolated) at that point, so I'm not certain we'll be able to do what you want here.

As a workaround, I'd suggest using a provisioner to add this to the cloud-config file (though this implies you'll be able to connect, which I assume is the whole point of this addition), or alternatively, to provide your own SSH private/public keys that you can interpolate with a reference to a variable.

Something like the following:

variable "ssh_public_key" {
  type = string
}

source "qemu" "build" {
[...]
      ssh_authorized_keys:
        - file(var.ssh_public_key)
      EOF
[...]
}

Hope that helps!

[timeu]

@lbajolet-hashicorp : thanks for the response. The PR for the vmware plugin gave me the impression that it works. I can try to apply the change to the qemu plugin and test it locally and report back and if it works create a PR forr it. Right now we provide an ssh key pair but it would be nice if we could simply leverage the ephemeral ssh key support and not have to provide a dedicated key-pair.

[lbajolet-hashicorp]

Hi @timeu,

Out of curiosity, may I ask which PR you are referring to? It is possible I missed something which would make it possible, though at first glance I would still think we have a bootstrapping problem, but I'll be happy to be proved wrong on this one!

If you are willing to do a PR with an implementation please feel free to do so, and let me know when it's ready to be reviewed, I'll definitely take a look at it, thanks!

[timeu]

@lbajolet-hashicorp : Sorry forgot to mention the PR. It's this one: https://github.com/hashicorp/packer-plugin-vmware/pull/203

[LIV2]

I tested this myself but it still didn't work when I reordered the steps, I think @lbajolet-hashicorp is correct that the interpolation happens too early for this to work

I make use of the variable by adding this to the boot args before ---

PACKER_AUTHORIZED_KEY={{ .SSHPublicKey | urlquery }}

Then use late-commands in the Ubuntu autoinstall config to install the key

  late-commands:
    - mkdir -p /target/etc/ssh/sshd_config.d
    - echo "PermitRootLogin prohibit-password" > /target/etc/ssh/sshd_config.d/permitroot.conf
    - mkdir -p -m 700 /target/root/.ssh
    - 'grep -oP "PACKER_AUTHORIZED_KEY\=\K\S+(?=%0A)" /proc/cmdline | sed "s@+@ @g;s@%@\\\x@g" | xargs -0 printf "%b" >> /target/root/.ssh/authorized_keys'
    - chmod 600 /target/root/.ssh/authorized_keys

[timeu]

Yes, I tried it myself and I can confirm the findings of @LIV2 :-/ There is a related issue open in the packer repo I think we can close this ticket.

[anshulsharma-hashicorp]

As discussed above source need to be complete before builder run, @timeu as per your confirmation closing this one.