Overview of the Issue
Previously I had an issue when providing a private SSH key to connect to my newly created droplet: #19
The fix provided in #20 and shipped with v1.0.1 fixed my issue and I've been using that version ever since.
Now I'm (finally) upgrading to a more recent version and my existing configuration results in a different error.
The private key specified in my config is being used as both the root key when creating the droplet and the ssh key when connecting as a user (which may not be root) to provision the droplet.
In my case, I have a user named deploy that already exists on the base image that I want to connect as. Giving root the same key as deploy is no bueno.
I noticed this because I have that key added to DO already separately, and when trying to create the root key it fails since there's a duplicate.
I believe this bug emerged in the following commit: 0462cbc
Versions of the plugin pre-1.2.0 work as expected.
My desired functionality is to be able to specify the root key and the communicator key separately. If I don't specify a root key then the plugin should generate a temporary one for me, but then connect using the supplied communicator user/key.
Reproduction Steps
- Create a keypair on the host where you're running packer.
- Add that key to Digital Ocean.
- Create a packer buildfile that specifies the private key file but not the key ID from Digital Ocean
- Run
packer build
- Observe the output (example below)
Plugin and Packer version
Packer: 1.9.4
Plugin: 1.2.0 and up
Simplified Packer Buildfile
variable "deploy_private_key_file" {
type = string
default = null
}
variable "digital_ocean_application_image_id" {
type = string
default = null
}
build {
name = "application_server"
source "source.digitalocean.default" {
image = var.digital_ocean_application_image_id
snapshot_name = "backend_server"
snapshot_regions = ["tor1", "nyc3"]
ssh_username = "deploy"
ssh_private_key_file = var.deploy_private_key_file
}
}
Operating system and Environment details
MacOS 13.6.3
Log Fragments and crash.log files
Full plugin output from my packer run:
Debug mode enabled. Builds will not be parallelized.
application_server.digitalocean.default: output will be in this color.
==> application_server.digitalocean.default: Using existing SSH private key
==> application_server.digitalocean.default: Pausing after run of step 'StepSSHKeyGen'. Press enter to continue.
==> application_server.digitalocean.default: Pausing after run of step 'nullStep'. Press enter to continue.
==> application_server.digitalocean.default: Importing SSH public key...
==> application_server.digitalocean.default: Error creating temporary SSH key: POST https://api.digitalocean.com/v2/account/keys: 422 (request "e362b52b-ac39-4c99-b14f-cb6bf0804dc0") SSH Key is already in use on your account
==> application_server.digitalocean.default: Pausing before cleanup of step 'nullStep'. Press enter to continue.
==> application_server.digitalocean.default: Pausing before cleanup of step 'StepSSHKeyGen'. Press enter to continue.
Build 'application_server.digitalocean.default' errored after 20 seconds 184 milliseconds: Error creating temporary SSH key: POST https://api.digitalocean.com/v2/account/keys: 422 (request "e362b52b-ac39-4c99-b14f-cb6bf0804dc0") SSH Key is already in use on your account
Overview of the Issue
Previously I had an issue when providing a private SSH key to connect to my newly created droplet: #19
The fix provided in #20 and shipped with
v1.0.1fixed my issue and I've been using that version ever since.Now I'm (finally) upgrading to a more recent version and my existing configuration results in a different error.
The private key specified in my config is being used as both the root key when creating the droplet and the ssh key when connecting as a user (which may not be root) to provision the droplet.
In my case, I have a user named
deploythat already exists on the base image that I want to connect as. Givingrootthe same key asdeployis no bueno.I noticed this because I have that key added to DO already separately, and when trying to create the root key it fails since there's a duplicate.
I believe this bug emerged in the following commit: 0462cbc
Versions of the plugin pre-1.2.0 work as expected.
My desired functionality is to be able to specify the root key and the communicator key separately. If I don't specify a root key then the plugin should generate a temporary one for me, but then connect using the supplied communicator user/key.
Reproduction Steps
packer buildPlugin and Packer version
Packer: 1.9.4
Plugin: 1.2.0 and up
Simplified Packer Buildfile
Operating system and Environment details
MacOS 13.6.3
Log Fragments and crash.log files
Full plugin output from my packer run: