Host Key Activation Timing Difference - OpenSSH 8.7 vs 9.9

[UDIYANA Ramya]

Hello OpenSSH Team,

I'm a developer working on OXE (Alcatel-Lucent telecommunication platform) and discovered a timing difference in host key activation between OpenSSH 8.7 and 9.9 when deploying new SSH host keys.
We would appreciate your guidance on whether this is intentional and the recommended approach for automation.
________________________________
OBSERVED BEHAVIOR:
OpenSSH 8.7:

  *
After copying new RSA key to /etc/ssh/ssh_host_rsa_key
  *
ssh-keyscan immediately retrieves the NEW key
  *
No restart required for key activation

OpenSSH 9.9:

  *
After copying new RSA key to /etc/ssh/ssh_host_rsa_key
  *
ssh-keyscan retrieves OLD key (sshd still using old key)
  *
After systemctl restart sshd
  *
ssh-keyscan then retrieves the NEW key

________________________________
REPRODUCIBLE TEST CASE:
=== OpenSSH 8.7 ===
Step 1: Generated new RSA key
$ ssh-keygen -t rsa
Step 2: Copied to system host key location
$ cp /root/.ssh/id_rsa /etc/ssh/ssh_host_rsa_key
$ cp /root/.ssh/id_rsa.pub /etc/ssh/ssh_host_rsa_key.pub
Step 3: Verified files match
$ diff /root/.ssh/id_rsa.pub /etc/ssh/ssh_host_rsa_key.pub
[No difference - files identical]
Step 4: Scanned IMMEDIATELY without restart
$ ssh-keyscan -t rsa loopback
loopback ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCv+//K0nXg...
Step 5: Scanned AFTER systemctl restart sshd
$ systemctl restart sshd
$ ssh-keyscan -t rsa loopback
loopback ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCv+//K0nXg...
RESULT: ✓ Same key in both scans (consistent)

=== OpenSSH 9.9  ===
Step 1: Generated new RSA key
$ ssh-keygen -t rsa
Step 2: Copied to system host key location
$ cp /root/.ssh/id_rsa /etc/ssh/ssh_host_rsa_key
$ cp /root/.ssh/id_rsa.pub /etc/ssh/ssh_host_rsa_key.pub
Step 3: Verified files match
$ diff /root/.ssh/id_rsa.pub /etc/ssh/ssh_host_rsa_key.pub
[No difference - files identical]
Step 4: Scanned IMMEDIATELY without restart
$ ssh-keyscan -t rsa loopback
loopback ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDvSkvXWWVpHqV...
↑ Key A (old)
Step 5: Scanned AFTER systemctl restart sshd
$ systemctl restart sshd
$ ssh-keyscan -t rsa loopback
loopback ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDNRNmMycV0B0t...
↑ Key B (new)
RESULT: ✗ Different key before and after restart

KEY FINGERPRINTS:
Before restart (9.9): SHA256:5vkOBJd5TtC3+H/B0cMH/GQ8/XUW454wvuXcRlxiSAo
After restart (9.9): SHA256:5vkOBJd5TtC3+H/B0cMH/GQ8/XUW454wvuXcRlxiSAo
(Now matches /root/.ssh/id_rsa)
________________________________
QUESTIONS:

  1.
Is the 9.9 behavior (delayed key activation) intentional?
  2.
Should deployment automation always execute systemctl restart sshd immediately after writing new host keys?
  3.
Is there a recommended way to activate keys without full sshd restart (e.g., kill -HUP, or sshd signal handling)?
  4.
Is this a regression from 8.7, or an intentional security enhancement in 9.9?

________________________________
BUSINESS IMPACT:
Our OXE automation calls ssh-keyscan immediately after key deployment to populate /root/.ssh/known_hosts. On 9.9, this captures stale keys, causing false MITM warnings on subsequent SSH connections.
The impact is significant because:

  *
Users see: "REMOTE HOST IDENTIFICATION HAS CHANGED!"
  *
Legitimate connection is blocked
  *
Automation must manually restart sshd (extra step)

________________________________
ENVIRONMENT:

  *
OpenSSH 8.7: Rocky Linux 8 (legacy system)
  *
OpenSSH 9.9: Rocky Linux 9 (modern system)
  *
Both using RSA 4096-bit keys
  *
OXE platform (Alcatel-Lucent telecommunications)

________________________________
Thank you for any guidance you can provide. This would help us ensure proper key management across all OpenSSH versions.

Best regards,
Ramya U