Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return OpenSSH formatted values/attributes for items of type SSH Key #189

Open
dominikmueller opened this issue Jul 18, 2024 · 6 comments
Open
Labels
enhancement New feature or request

Comments

@dominikmueller
Copy link

Summary

SSH Keys currently return the string value of the private key field. This feels a bit strange since the OP cli and UI would return the keys in OpenSSH format when revealing/copying the private key.

See https://1password.community/discussion/142994/beg-report-ed25519-ssh-private-keys-human-readable-value-differs-from-json-value for more information regarding the difference between the private key value field and the available values from ssh_formats.

Use cases

Consistent/WYSIWYG behaviour between terraform provider resources and UI/op-cli.

Proposed solution

Either always return the openssh formatted key for the private_key attribute or add another attribute that returns the openssh format - e.g. private_key_openssh? Or vice versa (e.g. private_key_pem_pkcs8).

Maybe use the tls providers attributes as a template to keep the resources alligned: https://registry.terraform.io/providers/hashicorp/tls/latest/docs/resources/private_key#read-only

Is there a workaround to accomplish this today?

Not sure. Feels kind of difficult/unnecessary to manually convert SSH keys in terraform.

References & Prior Work

OP-Cli also returns the OpenSSH format instead of the field value by default.

@dustin-ruetz
Copy link
Contributor

Hi @dominikmueller 👋 Thanks for your interest in our Terraform provider and for filing this issue.

Our team doesn’t currently have enough available bandwidth to prioritize this feature, but we really appreciate your detailed write-up here and your rationale for requesting this enhancement. We’ll keep an eye on this issue (and its emoji votes as indicators of interest from other customers) and possibly look into implementing this feature in the future.

@shearn89
Copy link

shearn89 commented Oct 9, 2024

I've just bumped in to this - I've pulled an SSH key from 1p to use as a deployment key in Argo, and the fact that it's not OpenSSH format has meant the sync with my GitHub repo fails. I now need to either inject that key a different way, or mangle it in Terraform somehow...

@kquinsland
Copy link

Damn, I just got hit by this too.

The ?format=openssh trick doesn't work, either :(

data "onepassword_item" "some_deploy_key" {
  # working, does correct thing:
  #   op read "op://VAULT/repo deploy key/private key?ssh-format=openssh"
  ##
  # Does not work, yields:
  # Unable to read item, got error: op error: "repo deploy key/private key?ssh-format=openssh" isn't an item in the "VAULT" vault. Specify the item with its UUID, name, or domain.

  title = "repo deploy key?ssh-format=openssh"
}

@mmack
Copy link

mmack commented Dec 13, 2024

same here... please consider fixing this...

@litui
Copy link

litui commented Dec 23, 2024

Bump. This needs fixing.

@TechDufus
Copy link

Bump. Here's my scenario:

I store the pub/priv keys in OP. When creating an EC2 in AWS, I provide the pub key so I can have SSH access, but I need to inject the private key (via a file provisioner (below)) since it is a GitHub deploy key to pull private repos. But as stated above, this is in the raw (non-openssh) format.

  provisioner "file" {
    content     = data.onepassword_item.ssh_key.private_key
    destination = "/home/ec2-user/.ssh/id_rsa"

    connection {
      type        = "ssh"
      user        = "ec2-user"
      private_key = data.onepassword_item.ssh_key.private_key
      host        = self.public_ip
    }
  }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants