Why is one of my machines refusing to accept ssh into the root account?

I have a cluster of 7 machines. All run Linux; 5 of them running Xubuntu 20.04.5, including all three I'll mention here. All have a root account and one user account. I am the only actual user; this is a hobby.

They are set up largely identically, to keep my life simple. Nevertheless, one of the machines refuses to accept incoming SSH connection to the root account, although connections to the root account are accepted by all of the other 6 hosts. The symptom is just the usual "Permission denied (publickey)."

All account keys are ed25519. There is just one authorized_keys file for root and one for the user, copied to all 7 machines.

For testing and describing this problem with some precision, I focused on three machines. One was the host that refused connedtions, one was going to attempt the connection, and the third was for comparison. Lets call the machines c, p and g (so that I can keep them straight). I logged into root on p and could from there log into root on g but not to c. I compared some files on g and c, and found them identical: /root/.ssh/authorized_keys /etc/sshd_config and all 3 files in /etc/ssh/sshd_config.d; moreover, all of these files were owned by root.

Meanwhile, g could log into the user account on c, both from its own root and its own user accounts, thus affirming that the SSH server on c is functioning.

One oddity that deserves note: when I ran ssh -vvv c on p, the output said it was trying two different private keys, but in both cases then said no such identity. Neither of them was the identity that does exist: /root/.ssh/id_ed25519. It tried id_ed25519_sk and id_xmss. Since the config files all match, and connection works via id_ed25519 to the user account, I have no idea why it skips that one.

The question: where else can I look for a difference that may be causing this? Something is.

Not getting much response here, I may have to do what I dread.

There is always the hard way, and I've done it more than a few times. Sometimes it´s called “bifurcation”, other times it's called “start over”. And by that I mean install the same Linux in a different partition. Install ssh-server and configure its SSH just like one of the other machines. See if it accepts incoming root SSH connections. If so, I´ll know the rest will work, albeit very tediously.

The rest is to step-by-step try to recreate the failed system, testing SSH at every step. Either it will begin to fail — which will give a clue as to where the problem was — or else everything goes smoothly. In the latter case, I will not have learned the answer to this question, but it won´t matter any more — I´ll just use the new install.

When I´m done, I may mark this answer accepted. We´ll just have to see.