I have user $USER which is a system user account with an authorized users file. When I have SELinux enabled I am unable to ssh into the server using the public key. If I setenabled 0, $USER can now log in.

What SELinux bool/policy should I change to correct this behaviour without disabling SELinux entirely?

It's worth noting that $USER can login with a password under this default SELinux configuration, I'd appreciate some insight as to what is happening here, and why SELinux isn't blocking that. (I will be disabling password authentication altogether after this is resolved so this question is more nice to know)

  • 1
    If you set SELinux in permissive mode, what log message appears when the user logs in? Since this is a system account, you may need to add a rule to enable access to SSH keys outside /home; I don't know how to write that rule. Jun 13, 2014 at 3:30
  • can you share your SELinux conf ?
    – akash
    Jun 13, 2014 at 5:11

2 Answers 2


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
  • Thank you - this occurred for me on an AWS host where I relocated /home from the root disk to a separate disk mounted at /home. All resolved now.
    – Criggie
    Jun 19, 2020 at 2:16
  • This info was what I needed, but I'm wondering why this isn't some sort of default? Do all users have to have this restorecon command executed for them? Or is there some way to configure the system to allow it for all users? Is the access for anything more than the specific ~/.ssh/authorized_keys file actually needed? Feb 17 at 21:35

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".
    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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .