Packer creates RSA pair key even when ed25519 specified

[myslak71]

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

Overview of the Issue

temporary_key_pair_type = ed25519 isn't respected when using SSM - pair key created by packer still uses RSA resulting in failed connection. Checking AWS Console shows that created pair uses RSA indeed.
When packer version was changed to 1.8.0 it worked like charm.
Found an old issue: #11686 stating that's resolved - seems we're experiencing regression here.

Reproduction Steps

Steps to reproduce this issue

Packer version

1.10.3

Simplified Packer Template

source "amazon-ebs" "failing_ami" {
  ami_description = "Failing AMI."
  ami_name        = "Some AMI"
  instance_type   = "t3a.medium"
  region          = "us-east-1"
  source_ami      = "t3a.medium"
  ssh_username    = "ec2-user"
  communicator         = "ssh"
  ssh_interface = "session_manager"
  iam_instance_profile ="Profile-With-SSM-Access"
  temporary_key_pair_type = "ed25519"
}

Operating system and Environment details

Ubuntu 22.04
64 bit

Log Fragments and crash.log files

    amazon-ebs.failing-ami: Adding tag: "Name": "Packer Builder"
    amazon-ebs.failing-ami: Instance ID: i-02add91ca24b0d56f
==> amazon-ebs.failing-ami: Waiting for instance (i-02add91ca24b0d56f) to become ready...
==> amazon-ebs.failing-ami: Using ssh communicator to connect: localhost
==> amazon-ebs.failing-ami: Waiting for SSH to become available...
    amazon-ebs.failing-ami: Starting portForwarding session "ci-job-id-4937542-0dc1e498cdfacd8e6".
    amazon-ebs.failing-ami: Starting session with SessionId: ci-job-id-4937542-0dc1e498cdfacd8e6
    amazon-ebs.failing-ami: Port 8697 opened for sessionId ci-job-id-4937542-0dc1e498cdfacd8e6.
    amazon-ebs.failing-ami: Waiting for connections...
    amazon-ebs.failing-ami: Connection accepted for session [ci-job-id-4937542-0dc1e498cdfacd8e6]
==> amazon-ebs.failing-ami: Error waiting for SSH: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
==> amazon-ebs.failing-ami: Terminating the source AWS instance...
==> amazon-ebs.failing-ami: Bad exit status: -1
==> amazon-ebs.failing-ami: Cleaning up any extra volumes...
==> amazon-ebs.failing-ami: No volumes to clean up, skipping
==> amazon-ebs.failing-ami: Deleting temporary security group...
==> amazon-ebs.failing-ami: Deleting temporary keypair...
Build 'amazon-ebs.failing-ami' errored after 2 minutes 53 seconds: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

[lbajolet-hashicorp]

Hi @myslak71,

This is likely an AWS plugin problem more than a Packer one here, but may I ask which version of the plugin you're using? We don't bundle plugins anymore with Packer, so chances are you are using an old version of the plugin, hence why this happens.

I won't rule out the possibility that it's a bug just yet, but could you double-check that before we delve more into the details of this?

Thanks!

[myslak71]

I haven't specified

packer {
  required_plugins {
    amazon = {
      source  = "github.com/hashicorp/amazon"
      ...
    }
  }

explicitly in my code. How can I check running version then?

[lbajolet-hashicorp]

Hey @myslak71,

required_plugins are a nice to have in order to document/constrain the plugins required and the versions, but they're not necessarily your best weapon in order to figure out which plugins are effectively loaded.

For this I suggest looking at the verbose logs (enabled with the PACKER_LOG=1 environment variable), there you'll be able to see the plugin binary being loaded, and if you must know the version of that plugin (it may not be apparent in the binary's name), I suggest calling the describe command on it: packer-plugin-amazon describe.
This should print a JSON description of the plugin, including its version.