The issue is whether 'StrictModes' is overly strict or not, and more specifically with regard to a non-root group ID on the SSH host key files.

When deploying a new group name ('ssh_key') with purpose of centralizing the keys to a specific group ID, this works with v9.0p1 and has worked since v1.2.1 heydays.

But the above only works if 'StrictModes no' option is used.
I think the scenario above is stable enough to be able to enable 'StrictModes yes'.

So I propose that the UID-centric file permission logic associated with `options.strict_modes` config variable be loosen up a bit to accomodate the following acceptable file permission settings:

  File: /etc/ssh/ssh_host_XXXX_key
  Owner:  read-only (+r-wx) or read-write (+rw-x)
  Group:  none (----) or -- > read-only (+r-wx) < -- the major change
  Other:  none
  Notation:  0600, 0400, 0640, 0440 allowed

The new permissive settings above would apply, IF and only IF under following ONE condition:

  UID:    root(0)
  GID:    non-root    <-- the major change

  
And that would enable the key management software to maintain the key files without encroaching on other SSH configuration (or daemon-related) files.

I do believe this proposal to be equally applicable toward Principal Certificate files as well.



My Code Review Insights:
Process: sshd
'AuthenticateMethods': hostbased
Channel type: auth (pre-channel)
Method: publickey-hostbound-v00@openssh.com
CLI option: -o StrictModes=
Process context: main()/server
Variable: options.strict_modes
Source (read): match_principals_file()/user_cert_trusted_ca()/user_key_allowed()/userauth_pubkey()
Source (read): auth_rhosts2()/hostbased_key_allowed()
Source (read): user_key_allowed2()