Ssh key login not working with root

ssh key login not working with root, it works with any other account, and I have them keyed the same way, and I am new to Rockey, long time CentOS, and I know I set ssh keys right, they work on all the user accounts I have, and I did notice root is allowed ssh in the config, I cannot think of any other reason, I set the permission correctly.

chmod u+rwx,go-rwx /root/.ssh;
chmod u+rw,go-rwx /root/.ssh/authorized_keys 

I have tried to delete the folder, and recreate it using

ssh-copy-id -i ~/.ssh/ root@IP_ADDRESS

I also tried

scp ~/.ssh/ root@IP_ADDRESS:/root/

The keys get created

Is this normal? I cannot imagine this is supposed to be this way.

I have tried both, and this only affects the root, it works fine with all other accounts.

ssh-keygen -t ed25519 
ssh-keygen -t rsa -b 4096

Thanks, Flesh

Do the logs, like /var/log/secure, or client verbosity (ssh -v root@IP_ADDRESS) reveal why keys fail?

usually the logs can offer some clues.
on client: ssh -vvv ...
on server: journalctl -n20 -u sshd

did you check/set se context (root may have special type… [I never use root])? ls -alZ /root/.ssh

While you are setting ssh key login, it may be worth to consider ssh certificates.

You are not supposed to connect to ssh as root.
I don’t know if this is Rocky 8.x or 9.x, but there was a change to the setting that allows root login. e.g.

#PermitRootLogin yes
PermitRootLogin prohibit-password

Thanks, that makes sense, I found this information on the ssh site sshd_config - How to Configure the OpenSSH Server?, this is what I wanted, I like to key everything so passwords are not required, what was scary about this option, is that the key is not working on the root, what if this locks me out, so I add another user to sudoers to play it safe.

This also works, but is not recommended over using PermitRootLogin prohibit-password'

X11Forwarding yes
AllowAgentForwarding yes 
PermitRootLogin yes

Now I get it.

Update: A few times it worked, I have to dig into this more.


Using the ‘yes’ option seem dangerous to me, because someone could start hammering it with root:abc, root:123 and so on. I always connect as standard user and then use sudo if needed.

Yes, optimally one has PermitRootLogin no and connects only with regular account. (Ansible plays can use that too.)

On EL9 the PermitRootLogin prohibit-password is the default. (Installer has “allow password” check-box that adds – if selected – a file into /etc/ssh/sshd_config.d/ with PermitRootLogin yes)
EL8 still defaults to the much more vulnerable PermitRootLogin yes (and does not have /etc/ssh/sshd_config.d/ at all).

None of that does explain why key-pair authentication fails.


I may be wrong but I was under the impression the following restricted root to key authentication:

PermitRootLogin yes
PubkeyAuthentication yes
PasswordAuthentication no

I usually temporarily set PasswordAuthentication yes, so I can copy the key over.

Thanks Tom.


Edit just confirmed this with a server already had setup with above config:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

If you set PermitRootLogin prohibit-password then only public key access is possible on the root account, even if password authentication is set to yes. In this way, you can connect as a standard user using password, to copy the key across. If you then wish that key to be used by the root user, you can then copy it from /home/whateveruser/.ssh to /root/.ssh and fix the permissions.

At whichpoint, after this, password authentication can be set to no, to stop normal users using passwords to connect.


I have started to use minimal kickstart file for EL9 installs so that the key gets added already during install. (PXEboot installs – and for VMs the ‘cloud-init’ – conveniently do have that option.)

If you deny password authentication from everybody, then it is disabled from root too.
With PermitRootLogin you can be more strict with the account ‘root’ than with others.

1 Like

The discussion about “good practices” aside, are the following true:

  • Regular accounts can authenticate with password
  • Regular accounts can authenticate with keys
  • root can authenticate with password
  • root (usually?) fails to authenticate with keys

Which is rather special combination.

One can, with pam_access, have additional restriction rules (e.g. limit root access to short list of hosts), but I doubt they could match type of authentication.