8

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. – Gilles 'SO- stop being evil' Jun 13 '14 at 3:30
  • can you share your SELinux conf ? – akash Jun 13 '14 at 5:11
10
+50

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
| improve this answer | |
  • 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 at 2:16
2

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.