Packer clears the /home/root/.ssh/authorizedkeys before it begins to build child image.

[9charlie]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

When filing a bug, please include the following headings if possible. Any
example text in this template can be deleted.

Overview of the Issue

A paragraph or two about the issue you're experiencing.

I need this file to persists, as I am adding keys to it in the parent image build. How do I prevent this ? In the cloud init log on the temp packer vm, before any build starts, I see this

2024-12-18 19:04:54,639 - handlers.py[DEBUG]: start: azure-ds/get_public_ssh_keys: get_public_ssh_keys
2024-12-18 19:04:54,639 - azure.py[DEBUG]: Retrieved 1 keys from IMDS
2024-12-18 19:04:54,639 - handlers.py[DEBUG]: finish: azure-ds/get_public_ssh_keys: SUCCESS: get_public_ssh_keys
2024-12-18 19:04:54,640 - util.py[DEBUG]: Reading from /etc/ssh/sshd_config (quiet=False)
2024-12-18 19:04:54,641 - util.py[DEBUG]: Read 3435 bytes from /etc/ssh/sshd_config
2024-12-18 19:04:54,643 - util.py[DEBUG]: Reading from /home/packer/.ssh/authorized_keys (quiet=False)
2024-12-18 19:04:54,644 - util.py[DEBUG]: Read 425 bytes from /home/packer/.ssh/authorized_keys
2024-12-18 19:04:54,644 - util.py[DEBUG]: Writing to /home/packer/.ssh/authorized_keys - wb: [600] 850 bytes
2024-12-18 19:04:54,645 - util.py[DEBUG]: Reading from /etc/ssh/sshd_config (quiet=False)
2024-12-18 19:04:54,645 - util.py[DEBUG]: Read 3435 bytes from /etc/ssh/sshd_config
2024-12-18 19:04:54,646 - util.py[DEBUG]: Changing the ownership of /home/root to 0:0
2024-12-18 19:04:54,646 - util.py[DEBUG]: Changing the ownership of /home/root/.ssh to 0:0
2024-12-18 19:04:54,646 - util.py[DEBUG]: Writing to /home/root/.ssh/authorized_keys - wb: [600] 0 bytes
2024-12-18 19:04:54,647 - util.py[DEBUG]: Changing the ownership of /home/root/.ssh/authorized_keys to 0:0
2024-12-18 19:04:54,647 - ssh_util.py[DEBUG]: AuthorizedKeysFile has an user-specific authorized_keys, using /home/root/.ssh/authorized_keys
2024-12-18 19:04:54,648 - util.py[DEBUG]: Reading from /home/root/.ssh/authorized_keys (quiet=False)
2024-12-18 19:04:54,648 - util.py[DEBUG]: Read 0 bytes from /home/root/.ssh/authorized_keys
2024-12-18 19:04:54,648 - util.py[DEBUG]: Writing to /home/root/.ssh/authorized_keys - wb: [600] 589 bytes
2024-12-18 19:04:54,649 - handlers.py[DEBUG]: finish: init-network/config-ssh: SUCCESS: config-ssh ran successfully

I believe this is wiping out the /home/root/.ssh/authorizedkeys and then adding the packer key to it. Is there any way I can prevent this?

Reproduction Steps

Steps to reproduce this issue

Packer version

From packer version

Simplified Packer Template

If the file is longer than a few dozen lines, please include the URL to the
gist of the log or use the Github detailed
format
instead of posting it directly in the issue.

Operating system and Environment details

OS, Architecture, and any other information you can provide about the
environment.

Log Fragments and crash.log files

Include appropriate log fragments. If the log is longer than a few dozen lines,
please include the URL to the gist of the log or
use the Github detailed format instead of posting it directly in the issue.

Set the env var PACKER_LOG=1 for maximum log detail.

[lbajolet-hashicorp]

Hi @9charlie,

There seems to be some confusion as to what happens here, and whose responsability this is.

The logs you attach come from your execution of cloud-init on the VM instance you're trying to build with Packer.
What happens during this phase is outside of Packer's control, and if there's a VM instance existing, then the build did start, but provisioning might hang if you don't have a key to authenticate with.

I'm not sure what you're trying to do exactly since I don't have a template or full logs, but this issue warrants being re-labelled as need-verification for now instead of bug, since it's not clear to me yet that this is a bug on Packer's side.

Thanks for the report