Add support for ED25519 key algorithm

[detro]

Background

Support for the ED25519 key algorithm has been a community-requested feature for this provider for a while. The first issue we could track down was filed in May 2018 (#26). Since then, multiple contributors attempted to bridge this gap (#32 in Nov 2018, #59 in Oct 2019, #85 in Oct 2020).

We want to take this opportunity to thank all the contributors (@jbboehr, @kaidence, @invidian, @nikolay) for the PR they submitted, and also to apologize for the long delay in getting this set of functionalities added to this provider. HashiCorp has a policy to prioritize stability and bug-fixes over any new feature for our “utility providers”; but given the demand for this feature, we decided to look into this and see how we could fit ED25519 inside the feature set.

Proposal

To serve the community at our best, we want to provide a well-rounded implementation that adds support for ED25519. Specifically, we want it to match the same functionality coverage as per the currently-supported RSA and ECDSA.

The implementation will include changes to the following entities, so that they accept ED25519 as input in their algorithm / key_algorithm configuration fields:

Resources:

• tls_private_key (tls_private_key resource: adding support for ED25519 key algorithm #151)
  • Additional field: private_key_openssh
• tls_cert_request (Adding support for ED25519 to all the *_cert resources #173)
• tls_locally_signed_cert (Adding support for ED25519 to all the *_cert resources #173)
• tls_self_signed_cert (Adding support for ED25519 to all the *_cert resources #173)

Data sources:

• tls_public_key (ED25519: updating tls_public_key data source #160)

As work proceeds, PRs will be linked back to this issue for full context.

References

Addresses: #26
Supersedes: #32
Supersedes: #59
Supersedes: #85

[tazjin]

On prioritisation, note that this is starting to become a serious problem with the ongoing deprecations of RSA keys.

For example, right now a complete deployment flow of NixOS machines on AWS does not work as RSA keys being disabled by default in SSH servers have led to a situation of subtle incompatibilites:

1. The SSH server will refuse connections with ssh-rsa keys by default, unless re-enabled in the configuration.
2. Terraform can only generate RSA and ECDSA keys.
3. AWS only supports RSA and ed25519 keys.
4. In order to update the config for 1. after bootstrapping a machine, a working SSH key is needed.

This means current workarounds are that custom AMIs with RSA enabled need to be created, or keys need to be imported by other means than generation inside of Terraform. These kinds of problems will likely only increase in number from here on.

[detro]

@tazjin thank you - yes, no worries, this is happening :)

[nikolay]

Thank you, @detro. We hope it's happening soon as we now generate those outside of Terraform.

[detro]

👍 @nikolay - I'm still finding my pace as the newest member of the HashiCorp team that maintain these, but yours and other PRs definitely helped to get this moving faster.

[jseiser]

It would be great if we could please get a release with the tls_private_key enabled.

tls_private_key

We are getting hardened RHEL 8 images from the security team, and we build custom AMI's with packer. Each ENV we create has a custom SSH key on the bastion host that is generated via terraform. As of this moment, terraform can no longer create working keys ( packer/golang ssh implementation breaks), so we have to either disable fips ( cant ) or have packer spin up public instances with temp keys.

If we could just create the proper keys in terraform this entire problem goes away.

Thank you.