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
.