A question about accepted SSH host key algorithms

[nakedape69]

When trying to upload a cloud-init snippet I keep running into the error message ssh: handshake failed: ssh: no common algorithm for host key; we offered: [ecdsa-sha2-nistp384-cert-v01@openssh.com], peer offered: [ecdsa-sha2-nistp256 ecdsa-sha2-nistp256-cert-v01@openssh.com ssh-ed25519 ssh-ed25519-cert-v01@openssh.com] which seems to indicate that the "SSH client" restricts its supported host key algorithms. Is this a explicit decision or an unintended consequence and can it be reconfigured without changing the code, e.g. environment variable or config file? If not, what is the rationale for the rather limited algorithm support?

I have tried changing the key and certificate formats (ecdsa and ed25519) on both server and client. I have tried using just a keyfile+authorized_keys and finally username+password in the provider ssh section but I get the same error regardless.

Regular SSH logins works fine with all the above combinations so I believe this to be an issue with the Golang crypto/ssh client which I'm led to understand this module uses.

Has anyone else run into this problem and found a solution? My googling has not led me anywhere productive but maybe that is just the current state of web search. :P

Software versions:

tofu version
OpenTofu v1.12.2
on linux_amd64

• provider registry.opentofu.org/bpg/proxmox v0.109.0
• provider registry.opentofu.org/hashicorp/local v2.9.0
• provider registry.opentofu.org/hashicorp/random v3.9.0
• provider registry.opentofu.org/hashicorp/tls v4.3.0

[bpg-dev]

Hey @nakedape69 👋🏼

This isn't a deliberate limit in the provider, but rather a consequence of how the SSH client picks host-key algorithms.

The provider sets HostKeyAlgorithms from the entries it finds for your host in ~/.ssh/known_hosts
(via the skeema/knownhosts library). It doesn't hardcode a short list.

The error you're seeing means this:

• the provider offered [ecdsa-sha2-nistp384-cert-v01@openssh.com], your known_hosts has a @cert-authority entry for this host with an ecdsa-nistp384 CA key, so that's the only algorithm the client advertises.
• peer offered ecdsa-sha2-nistp256[-cert], ssh-ed25519[-cert], your Proxmox host key/cert is nistp256/ed25519-based, never nistp384.

No overlap, therefore the handshake fails. This happens during host-key negotiation, before user auth, which is why changing keys/certs and switching to password didn't help.
Regular ssh works because OpenSSH advertises a much broader set.

It can't be reconfigured via env var / config file — and note the provider does not read ~/.ssh/config, so directives there are ignored.

As for the fix you could either:

• remove the host's entry from ~/.ssh/known_hosts (via ssh-keygen -R <host>). With no record, the client falls back to its full default algorithm set and the provider auto-adds the real key on connect.
• add a plain host-key entry matching what the server presents: ssh-keyscan -t ed25519 <host> >> ~/.ssh/known_hosts.