Open berquist opened 1 year ago
If this is something that you'd be willing to accept but have no one to do it, I could submit a PR myself.
I think it makes sense to allow to customize this if your environment only allows a specific type. @ashley-cui @vrothberg @baude WDYT?
It sounds like a reasonable feature. Let's agree on what we need and how to implement it before opening a PR though.
SGTM. I'm okay either with a --key-type
for generating a key, or a --key
flag that allows a user to pass in a previously generated key.
I have no preference and my only requirement is for customizable -t
, but in the event that someone wants to pass yet more flags to ssh-keygen
, passing the key is the most general solution. Then any remaining automation is the user's responsibility.
Maybe instead of creating new keys it would be easier to allow to inject an existing public key? That way the user can create keys in any way they like and even use already existing keys.
Is there anything I can do to help this along?
@baude WDYT?
Again, I can try submitting an PR with the implementation if that would help move things along. No one where I work can run Podman on their Mac because of this.
SGTM
Feature request description
podman machine ssh
fails, and digging in shows that the auto-generated key is Ed25519 https://github.com/containers/podman/blob/d1ddd03a64a4136eb7e4db5389b14e1320c2f27a/pkg/machine/keys.go#L18 but this is not an allowed key type on my locked down machine, it needs to be ECDSA (-t ecdsa
):Suggest potential solution
podman machine init
takes a parameter for the-t
argument ofssh-keygen
, or a roughly equivalent solution.Have you considered any alternatives?
Unfortunately a rework of https://github.com/containers/podman/blob/d1ddd03a64a4136eb7e4db5389b14e1320c2f27a/troubleshooting.md#solution-25 doesn't seem possible, since there is no password for the VM:
Additional context
No response