Unable to Import "ED25519" key into resource "aws_key_pair"

[jseiser]

Terraform CLI and Provider Versions

Terraform Version: 1.1.8

Initializing provider plugins...

• Finding latest version of hashicorp/random...
• Finding hashicorp/aws versions matching ">= 3.0.0, >= 3.63.0, >= 3.67.0, >= 3.72.0, ~> 4.0"...
• Finding latest version of hashicorp/tls...
• Installing hashicorp/random v3.1.3...
• Installed hashicorp/random v3.1.3 (signed by HashiCorp)
• Installing hashicorp/aws v4.12.0...
• Installed hashicorp/aws v4.12.0 (signed by HashiCorp)
• Installing hashicorp/tls v3.3.0...
• Installed hashicorp/tls v3.3.0 (signed by HashiCorp)

Terraform Configuration

resource "tls_private_key" "key" {
  algorithm = "ED25519"
}

resource "aws_key_pair" "generated_key" {
  key_name   = format("%s-%s", var.vpc_id_tag, var.platform_env)
  public_key = tls_private_key.key.public_key_openssh
  tags       = local.tags
}

Expected Behavior

The new ED25519 key should have been imported into AWS.

Actual Behavior

Error: error importing EC2 Key Pair (JLS-DEV): InvalidKey.Format: Key is not in valid OpenSSH public key format
status code: 400, request id: e9d5cfb0-d0c5-4ab1-90c6-4476526cb2ca

with aws_key_pair.generated_key,
on ssh.tf line 5, in resource "aws_key_pair" "generated_key":
5: resource "aws_key_pair" "generated_key" {

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

The above code, is what we use currently, to generate keys for the dev environments. but instead of ED225519, we use RSA.

The docs show public_key_openssh should still be valid, and the AWS docs show this type of key is supported and that my provider version is new enough to support it.

• https://registry.terraform.io/providers/hashicorp/tls/latest/docs/resources/private_key#public_key_openssh
• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html
• tls_private_key resource: adding support for ED25519 key algorithm #151

Code of Conduct

• I agree to follow this project's Code of Conduct

[detro]

Hi @jseiser - sorry about this issue.

I think there is a disagreement between libraries used by this provider and the AWS one, in regards to the presence of newlines.

First, the workaround is simple (example):

resource "aws_key_pair" "key" {
  key_name   = "key"
  public_key = trimspace(tls_private_key.bastion.public_key_openssh)
}

This issue is unfortunately a duplicate of #163 (comment). We tend to rely on MarshalAuthorizedKey(key PublicKey) in x/crypto/ssh.

Can you give using trimpspace() a go and let me know?

Meanwhile I'll consider our options here. It might just be a matter of updating the provider doc to suggest using trimspace() in case code that consumes it is unable to handle those newlines.

[detro]

Small correction: it seems like it's the AWS APIs themselves that throw an error - AWS provider just returns it. I noticed it by looking at the debug output reported in this ticket.

[jseiser]

@detro any reason this works on RSA keys though?

[detro]

@jseiser that's why I looked at the output: if it was a behaviour internal to the AWS provider, I could see us collaborating with the terraform-provider-aws team and change the behaviour.

But being it an API-returned error, that's a much harder thing to deal with: likely they have a slightly different logic on their end to deal with RSA vs ED25519.

I think the only safe way to deal with this and try to help future practitioners facing this issue, is to add some documentation in this provider, to explain that the field is produced with an appended \n by the underlying crypto library, and they should trimspace() it if a problem arises.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.