SELinux preventing ssh via public key

Assuming the filesystem permissions are correct on ~/.ssh/*, then check the output of

sealert -a /var/log/audit/audit.log

There should be a clue in an AVC entry there. Most likely the solution will boil down to running:

restorecon -R -v ~/.ssh

If sealert is missing on a system, as it was on a system I recently encountered, there is also the possibility of audit2allow:

$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc:  denied  { read } for  pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Breaking down the AVC:

avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556
    "sshd" was denied read on a file resource named "authorized_keys".
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
    SELinux context of the sshd process that attempted the denied action.
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    SELinux context of the authorized_keys file.

Though audit2allow did not concisely tell how to fix the issue, by looking at scontext and tcontext, the scontext value indicates the context needed while tcontext shows the unsatisfactory "authorized_keys" file context.

In this case, restorecon -R -v ~/.ssh by itself did not work, but applying the desired context did:

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

As needed, change resource names and/or context based on what is seen in the AVC. Precise details in this answer were constructed to resolve a problem related to "authorized_keys", but a solution could follow this model even if a different file or context is indicated in the AVC produced by sealert or audit2allow.