How to Configure Root SSH Login on Rocky Linux Safely
You can allow SSH login for the root account on Rocky Linux, but it is safer and easier to audit to use a regular administrative account with sudo. If direct root access is absolutely necessary, do not enable password login and allow only public key authentication, and then apply it after checking the settings and performing a separate session test.
First, review the recommended method
Logging in as a regular user and executing only the necessary commands with sudo reduces direct exposure of root credentials and allows keeping user-specific activity logs.
sudo useradd adminuser sudo usermod -aG wheel adminuser
After creating the account, register the public key and verify that sudo -v works in a new session. You should test this before closing your existing SSH connection to avoid lockout due to misconfiguration.
Check current SSH and root login settings
It is more accurate to check the final effective configuration using sshd -T, which combines include files and defaults, rather than looking at just one line in the configuration file.
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) ' sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \ /etc/ssh/sshd_config /etc/ssh/sshd_config.d
Settings under Match conditions can produce different results depending on the connecting user and source address. In complex environments, verify them by specifying actual conditions with sshd -T -C.
Prepare the root public key
Key Files and Permission Settings
Register the public key of a trusted administrator in root's authorized_keys. Replace the public key string in the command below with the actual public key on a single line.
sudo install -d -m 700 -o root -g root /root/.ssh echo 'ssh-ed25519 public_key_string administrator_identifier' | sudo tee -a /root/.ssh/authorized_keys sudo chown root:root /root/.ssh/authorized_keys sudo chmod 600 /root/.ssh/authorized_keys sudo restorecon -Rv /root/.ssh
Do not upload the private key to the server. When adding the public key, make sure that line breaks are not broken and that it does not duplicate an already registered key.
Public Key Restrictions
If the key is for automation only, you can limit the source of connection and executed functions with authorized_keys options such as from=, command=, and restrict. However, incorrect restrictions can interrupt operations, so first test them with a separate key.
Allow Root Login Only with Public Key
Rather than directly overwriting existing files, adding a purpose-specific file in a drop-in directory read by the distribution makes it easier to track changes.
sudo tee /etc/ssh/sshd_config.d/90-root-key-login.conf > /dev/null <<'EOF' PermitRootLogin prohibit-password PubkeyAuthentication yes EOF
prohibit-password disables root passwords and keyboard-interactive authentication, allowing only non-password methods like public keys. The final result may vary depending on the order of other configuration files and Match blocks, so always verify the final value.
Grammar check, separate session test from reflection
- Keep the current administrator session open.
- Check the grammar with
sshd -t. There should be no output and the exit status should be 0. - Reload the SSH service.
- Test root public key login in a new terminal.
- Verify that password login is denied and that the existing administrator account is functioning properly.
sudo sshd -t sudo systemctl reload sshd sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
If the grammar check fails, do not reload the service. Fix the file and line indicated by the error. Reload is preferable to restart to maintain existing connections, but it is safe not to close the current session until the new connection test is completed.
Ways to further limit the scope of access
Only allow the management network on the firewall
Do not expose the SSH port to the entire internet; only allow the original addresses of the VPN or the management network. The addresses below are examples for documentation purposes and should be replaced with the actual management network.
sudo firewall-cmd --permanent --zone=public --remove-service=ssh sudo firewall-cmd --permanent --zone=public \ --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept' sudo firewall-cmd --reload sudo firewall-cmd --zone=public --list-all
On the remote server, do not remove existing rules before verifying that the new allow rule matches the actual source of connections. It is safer to test with runtime rules first and secure a console recovery method.
Separate users and keys
- Issue different keys for each person and invalidate only that key when someone leaves or changes roles.
- Distinguish between automation keys and interactive management keys for humans.
- Set a passphrase on keys and only use agent forwarding if necessary.
- Collect SSH logs and abnormal authentication attempts centrally and raise alerts.
Cases where you absolutely must enable root password login
If you enable PermitRootLogin yes along with password authentication, brute-force attacks and credential leaks can immediately lead to full administrative access. If there are unavoidable reasons, such as old equipment, use it without exposing it directly to the Internet, and combine a VPN/management network, short application time, strong temporary passwords, and intensive monitoring.
PermitRootLogin yes PasswordAuthentication yes
This value is just an example configuration and is not recommended. Once the work is finished, immediately revert to key-only or disabling root login, and discard any used passwords.
Disabling direct root login again
If it is no longer needed, apply the following value in the drop-in file, then repeatedly check syntax and test in a new session.
PermitRootLogin no
Before disabling root login, first confirm that public key login and sudo work properly for a regular administrator account.
Items to check if problems occur
| Symptoms | Items to check |
|---|---|
| Public key is rejected | Check the permissions, owner, and SELinux context of /root/.ssh and authorized_keys. |
| Settings are not applied. | Check sshd -T, the include order, and Match conditions. |
| Connection timed out. | Check sshd listen address and port, firewalld, upper-level firewall, and routing. |
| Service reload failed. | Check syntax errors with sshd -t and journalctl -u sshd. |
Reference Documents
The exact meaning of PermitRootLogin, Match, and authentication-related settings can be found in the OpenSSH sshd_config official manual.









