PermitRootLogin default prohibit-password in OpenSSH 7.0 breaks legacy root SSH automation

Answer

Yes. Starting with OpenSSH 7.0, when PermitRootLogin is not explicitly set in sshd_config, the effective default is prohibit-password, which allows root login only via public‑key authentication and disables password authentication for the root account.

Confirmed facts

• OpenSSH 6.9 and earlier defaulted to PermitRootLogin yes (password‑based root login allowed unless overridden).
• The change to prohibit-password is documented in the OpenSSH 7.0 release notes and the sshd man page.
• Legacy automation that uses ssh root@host with a password (or sshpass) now fails with "Permission denied (publickey)".

Likely explanation

The stricter default improves security by preventing brute‑force password attacks on the root account. Scripts that relied on password authentication must either be updated to use key‑based auth or be granted a limited exception that does not weaken the overall default.

Steps to maintain compatibility without downtime

1. Verify the current effective setting (run on the target host):

   sshd -T | grep permitrootlogin
   

2. Create a temporary exception for the automation host (if the automation originates from a known IP or subnet). Add a Match block to sshd_config:

   Match Address 203.0.113.45
       PermitRootLogin yes
   

   Reload the daemon:

   systemctl reload sshd
   

3. Test password‑based root login from the automation host:

   ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@host true
   

   If the command returns successfully, the exception works.
4. Deploy key‑based authentication for the automation (generate a key pair, copy the public key to /root/.ssh/authorized_keys on the target, ensure the private key is available to the automation script). Test:

ssh -i /path/to/automation_key root@host true

5. Once key‑based login is verified, remove the Match Address block (or change it to PermitRootLogin prohibit-password) and reload sshd again. This returns the system to the secure default while the automation now uses keys.
6. If the automation host cannot be identified (e.g., dynamic IPs), consider using a forced‑command key pair: restrict the key in authorized_keys to a specific command or script, then update the automation to invoke that forced command via SSH. This maintains security without granting broad password access.

Missing diagnostic detail

If you cannot determine whether the automation originates from a known, static IP address, please confirm whether the automation source IP is stable or can be made static; this determines whether a Match Address exception is viable or if a forced‑command key approach is required.