SELinux prevents ssh with RSA key

Question

I forgot that I had enabled SELinux on one of my web servers. So when I went to log into the host with my user account and ssh key, I was getting permission denied errors.

[TimothyDunphy@JEC206429674LM:~] #ssh [email protected]
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Hmmm... So I consoled into the server and was able to login. I tailed the audit logs, and this is what I saw:

type=USER_LOGIN msg=audit(1429981690.809:394593): pid=17074 uid=0     auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023     msg='op=login acct="bluethundr" exe="/usr/sbin/sshd" hostname=? addr=47.18.111.100 terminal=ssh res=failed'

In googling for the answer to this I got the advice to run this command:

[root@web1:~] #restorecon -R -v /home/bluethundr/.ssh
[root@web1:~] #

But when I go to login again, after doing that, I get the same result. Permission denied and the same error in the logs.

The only other thing I can think of is that the home directory for the user is mounted from an NFS share. Might there be some SELinux incantation I can use to allow SSH to a home directory on an NFS share?

Or maybe I'm missing something else?

Thanks, Tim

Answer 1

If restorecon didn't work, I generally try audit2why and/or audit2allow to find what policy is being violated. That's not to say that I apply the policy change suggestions that are generated, just that they lead to very good information to resolving the issue.

Answer 2

Bingo!!

When I ran audit2why -w this was the output I saw:

 [root@web1:~] #grep ssh /var/log/audit/audit.log | audit2why -w
 Was caused by:
    The boolean use_nfs_home_dirs was set incorrectly.
    Description:
    Allow use to nfs home dirs

    Allow access by executing:
    # setsebool -P use_nfs_home_dirs 1
    type=AVC msg=audit(1429983513.529:394784): avc:  denied  { read } for  pid=19748 comm="sshd" name="authorized_keys" dev="0:40" ino=275968 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nfs_t:s0 tclass=file

So it looks like my hunch about it being about NFS and your suggestion to use audit2why allow me to crack the case!

[TimothyDunphy@JEC206429674LM:~/creds] #ssh [email protected]
Last login: Sat Apr 25 13:41:02 2015 from ool-2f126f64.dyn.optonline.net
[bluethundr@web1 ~]$

Bam!! It works. Thanks for your help!