As I have used a CA to signed each of my nodes' SSH certificates, the public certificate presented by the ssh server for each node is different to the unsigned node certificate which Promox copies into /etc/pve/nodes/nodename/ssh_known_hosts file.
I now noticed we had the conversation here in May, sorry.
Yes, PVE basically initializes these (what they called pinned) snippet files from the actual host keys, I believe on boot time now. There's nothing you can do about that, it's how their tooling goes about using SSH intra-cluster (it does not even matter, their SSH helper for constructing the command always adds custom options to avoid using global files).
Also Proxmox defaults to populating the RSA public certificate in the ssh_known_hosts file and I may have chosen to use an ED25519 public certificate instead.
So if you are asking me whether you can override this for PVE nodes connecting to each other with their own SSH tooling, not really, other than by custom patch. I had even previously filed
BZ on this. As you can tell, at Proxmox, there's always enough resources to invest in making the request somehow invalid or not applicable rather than doing the actual work.
The irony of this is, that the long promised SSL API only approach is also a
BZ for that - see how active that one is.
I always created a related BZ for any issue where "we will move away from SSH" was given as a reason, in the end I am now told I am creating too much spam with BZ updates.
At this point, I do not expect any help for someone like you (i.e. a user) for youself, consider the last
reply on the bad released notes on the current SSH change we are now discussing here:
> Users are confused [1] with the 8.2 release notes on fix 4886 (URL):
I can not see any confusion in the linked thread that directly stems for the release note but rather your tutorial and your replies.
Yes, this is how
@t.lamprecht replies to what they caused with this change and we have to discuss now here.
Next thing I will be accused of hijacking (my own?) thread by talking about "my" issues, I suspect.
With that out of the way (yes I am frustrated we have to discuss it here, NOT because of you
@kesawi, but becase they do not do their job):
Even if I retained the RSA certificate I would need to overwrite the existing unsigned certificate with the signed one rather than keeping it in a separate file.
Not really, not if you don't care what PVE tooling themselves use, i.e. if you only want own SSH keys (signed or not makes no difference), you should be using the common system files (which do not get overwritten), e.g.:
/etc/ssh/ssh_host_ed25519.pub for your own host key
/etc/ssh/ssh_known_hosts that you have to populate on every system (but not every reboot), if regular file, as always meant to be
I prefer to keep a copy of the original certificate untouched so I don't need to regenerate if from the private key or risk the signed key being overwritten through some automated process.
These should not be getting overwritten, or are they, for you?
Adding my @cert-authority to each of the /etc/pve/nodes/nodename/ssh_known_hosts files ensures that each of the nodes is recognised as legitimate by another node.
If there's any confusion still after the above was mentioned, let's clarify what "each of the nodes is recognised as legitimate by another node" means for you. Do you mean for manually invoking SSH from command line without extra options as a user would? That was my context above.
The use of a CA to sign SSH host certificates is good practice and there are also legitimate reasons why admins may wish to use different key algorithms other than RSA.
For your own needs, you can, for PVE stack alone, they already gave me enough dismissive answers why they would not (they are technically non-sensical, so either they do not understand SSH certs or they do not think their users do, whichever it is, I find it funny at the least).
