SSH Root Login Failed? Here's the Real Fix

I know seeing Permission denied (publickey) when trying to SSH as root is frustrating. Especially when you're in a hurry. Let's fix it now.

The Quick Fix: Two Lines in sshd_config

SSH root login fails because the server doesn't allow it. By default, most Linux distros (Ubuntu 22.04, Debian 12, CentOS 9) disable root SSH for security. But here's how to turn it back on.

1. Open the SSH config file as root:

sudo nano /etc/ssh/sshd_config

2. Find these two lines and change them:

PermitRootLogin yes
PasswordAuthentication yes

If the lines start with #, remove the # to uncomment them. If they say no or prohibit-password, change to yes.

3. Save the file (in nano: Ctrl+X, then Y, then Enter).
4. Restart SSH:

sudo systemctl restart sshd

Try SSH again. Should work now.

Why This Works

SSH has a config file at /etc/ssh/sshd_config. It controls everything about who can connect and how.

PermitRootLogin is the master switch. If it's set to no or prohibit-password, root can't log in with a password. prohibit-password means root can only use SSH keys (no password). Change it to yes and root can use a password.

PasswordAuthentication is the second switch. Even if PermitRootLogin yes is set, if PasswordAuthentication no, you can't use a password at all. Both must be yes for password-based root login.

This tripped me up the first time too. I changed PermitRootLogin but forgot PasswordAuthentication. Still got denied. Always check both.

Less Common Variations

1. SSH Key Only Setup

Some servers (like AWS EC2, DigitalOcean droplets) come with PasswordAuthentication no by default. If you want root password login, you must change it. But I recommend keeping key-only for cloud instances. Safer.

2. SELinux Blocking SSH

On RHEL, CentOS, and Fedora, SELinux can block root SSH even if the config is right. Check with:

sudo ausearch -m avc -ts recent | grep sshd

If you see denials, temporarily set SELinux to permissive to test:

sudo setenforce 0

If SSH works after that, the fix is to adjust the SELinux boolean:

sudo setsebool -P ssh_sysadm_login on

Then turn SELinux back on: sudo setenforce 1.

3. SSH Service Not Running

Sounds silly, but I've seen servers where sshd wasn't even running. Check:

sudo systemctl status sshd

If it's inactive, start it: sudo systemctl start sshd. Also enable it to start on boot: sudo systemctl enable sshd.

4. Firewall Blocking Port 22

UFW on Ubuntu or firewalld on CentOS can block SSH. Check:

sudo ufw status
# or
sudo firewall-cmd --list-all

If port 22 isn't allowed, open it:

sudo ufw allow ssh
# or
sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload

5. Wrong SSH Key Permissions

If you're using SSH keys, the .ssh folder and authorized_keys file must have strict permissions. On the server, as root:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If permissions are too open (e.g., 777), SSH refuses the key. I've seen this happen after copying files with cp -r.

How to Prevent This in the Future

Three things you can do right now to never see this error again:

• Take a backup of sshd_config before editing: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. If you mess up, restore from backup.
• Test SSH config before restarting: Run sudo sshd -t. This checks the config syntax. If it says nothing, you're good. If it shows an error, fix it before restarting.
• Keep a second SSH session open when making changes. If you lock yourself out, you can fix it from the second session. I learned this the hard way after locking myself out of a production server.

That's all. You're back in business. If it still doesn't work, check the logs: sudo tail -f /var/log/auth.log (Ubuntu/Debian) or sudo journalctl -u sshd -f (systemd-based distros). They'll tell you exactly why root was denied.