It is worth to mention that the current OpenSSH manual (as of
OpenSSH 9.0/9.0p1 (2022-04-08)) generally assumes that the owner of
authorized_keys file is the user who authenticates, hence
rw- --- --- in the table ("...read/write for the user, and not accessible by others.").
The main reason is that the SSH daemon/server by OpenSSH generally operates in this order I believe (assuming that the ssh service is running under
Checks whether the user who tries to authenticate exists in the environment;
2.1. In case there's no such, invalidates the request (e.g.
May 01 01:12:34 host sshd: Invalid user user3 from x.x.x.x port 12345);
Creates a separate sshd process with the UID and GID of the authenticating user;
In case of
pubkey, the new process tries to read the "authorized_keys" in the configured paths.
3.1. In case the new process cannot read "authorized_keys" file, exists, and that invalidates the request.
# pstree -pugT:
| `-tmux: client(194943,194943)
A source investigation is required to confirm the above, though to summarize, an OpenSSH server currently reads "authorized_keys" file as the authenticating user's UID and primary GID.
If the mode of "authorized_keys" is
600 and the file's owner is not the UID of the authenticating user, the authentication should fail. This may be a case when "authorized_keys" file were created by root for example.
This release deprecates the sshd_config UsePrivilegeSeparation option, thereby making privilege separation mandatory. Privilege separation has been on by default for almost 15 years and sandboxing has been on by default for almost the last five.
Related: https://serverfault.com/a/861842/345785 (...OpenSSH in version 7.5 deprecated the UsePrivilegeSeparation option...)