Allow customization of autogenerated SSH key type during `podman machine init`

[berquist]

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):

ssh -v -p$(podman machine inspect intel_64 | jq '.[].SSHConfig.Port') -i ~/.ssh/intel_64 core@localhost
OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 1: Applying options for *
debug1: /Users/username/.ssh/config line 9: Applying options for localhost
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/fips_ssh_config
debug1: /etc/ssh/ssh_config.d/fips_ssh_config line 1: Applying options for *
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to localhost port 61996.
debug1: Connection established.
debug1: identity file /Users/username/.ssh/intel_64 type 3
debug1: identity file /Users/username/.ssh/intel_64-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.0
debug1: compat_banner: match: OpenSSH_9.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:61996 as 'core'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HWFC/8xd3Y9FNmcuNiwD5oA4v6FIB0o/igZcgen5JtA
debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[localhost]:61996' is known and matches the ECDSA host key.
debug1: Found key in /Users/username/.ssh/known_hosts:24
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Skipping ssh-ed25519 key /Users/username/.ssh/intel_64 - corresponding algo not in PubkeyAcceptedAlgorithms
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: kex_input_ext_info: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: No more authentication methods to try.
core@localhost: Permission denied (publickey,gssapi-with-mic).

Suggest potential solution

podman machine init takes a parameter for the -t argument of ssh-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:

#!/bin/bash

# https://github.com/containers/podman/blob/d1ddd03a64a4136eb7e4db5389b14e1320c2f27a/troubleshooting.md#solution-25

set -euo pipefail

username=core
hostname=localhost
machine_name=intel_64

keyloc="${HOME}/.ssh/${machine_name}"

rm "${keyloc}" || true
rm "${keyloc}.pub" || true
ssh-keygen -t ecdsa -N "" -f "${keyloc}"
ssh-copy-id -i "${keyloc}.pub" "${username}@${hostname}"
podman system connection remove "${machine_name}"
podman system connection remove "${machine_name}-root"
uid="$(podman system connection list | grep '^intel_64\s' | cut -w -f 2 | cut -d'/' -f 6)"
podman system connection add ${username} \
       --identity "${keyloc}" \
       "ssh://${username}@${hostname}/run/user/${uid}/podman/podman.sock"
podman system connection add ${username}-root \
       --identity "${keyloc}" \
       "ssh://${username}@${hostname}/run/podman/podman.sock"

$ ./podman_ssh.bash
Generating public/private ecdsa key pair.
Your identification has been saved in /Users/username/.ssh/intel_64
Your public key has been saved in /Users/username/.ssh/intel_64.pub
The key fingerprint is:
SHA256:iVSk96uBMSOc4DgcThD82WIarwCynm8b/wpnH199YQc username@hostname
The key's randomart image is:
+---[ECDSA 256]---+
|+.     .o        |
|..     o         |
| oo o o .     E  |
|*+.B + o o     . |
|=+* = = S .    o.|
|oo . . =   .. . o|
|o oo o... .. . . |
| + .* . oo.   .  |
|  oo.ooo..       |
+----[SHA256]-----+
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/username/.ssh/intel_64.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
(core@localhost) Password:
(core@localhost) Password:
(core@localhost) Password:
core@localhost's password:
Permission denied, please try again.
core@localhost's password:
Permission denied, please try again.
core@localhost's password:
Received disconnect from ::1 port 22:2: Too many authentication failures

Additional context

No response

[berquist]

If this is something that you'd be willing to accept but have no one to do it, I could submit a PR myself.

[Luap99]

I think it makes sense to allow to customize this if your environment only allows a specific type. @ashley-cui @vrothberg @baude WDYT?

[vrothberg]

It sounds like a reasonable feature. Let's agree on what we need and how to implement it before opening a PR though.

[ashley-cui]

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.

[berquist]

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.

[Luap99]

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.

[berquist]

Is there anything I can do to help this along?

[Luap99]

@baude WDYT?

[berquist]

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.

[rhatdan]

SGTM

[rastna12]

Any update on this feature? I'm running into similar issues on my machine.