The clue I needed came in the messages file:
... setroubleshoot: SELinux is preventing /usr/sbin/sshd "read" access to authorized_keys. For complete SELinux messages. run sealert -l a2c5981a-546b-4541-bf3e-419b33a07f63
How handy is that! An error message with the answer built in. When you run the command, you get…
Summary: SELinux is preventing /usr/sbin/sshd "read" access to authorized_keys. Detailed Description: SELinux denied access requested by sshd. authorized_keys may be a mislabeled. sshd is allowed to read content in /root/.ssh directory if it is labeled correctly. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon restore using restorecon -R /root/.ssh. Fix Command: /sbin/restorecon -R /root/.ssh
First, I will have to read up on this restorcon and the extended attributes it is acting on, but it doesn’t explain the “.” at the end of the posix permissions.
Second, it’s trying to prevent me from doing something as stupid as remote login as root. Yes, yes, I know. For a temp dev system, to test a condition, on an isolated dev network, I don’t feel so bad.
I ended up following the advice from Red Hat and ran the following:
restorecon -R -v /root restorecon reset /root/.ssh context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0