diehn.net/blog

Yes, we all “hate” SELinux.  But, as I tell my kids, “hate” probably really means this:

prefer not to use it because it stops me doing things and since I don’t know how to manage it, I can’t do anything but turn it off entirely and feel dumb about it…. 🙂

However, it’s probably actually a good thing.  And it’s enabled by default on RHEL and Fedora now.  And we may see it adopted by other mainstream distros that market to commercial and government organizations.

So, I took a stab at it today.

Just after installing a fresh RHEL 6 Server, I went to enable private key authentication between account@{our other server} and account@{this new server} – needed for a certain process that {the new server} will support.

So, I copied the public key from  “account@{our other server}”  to the .ssh/authorized keys file in the home directory for “account@{the new server}”.  I did the right chmod magic.  In the past, that’s it – from then on we can ssh from one machine to the other with no passwords.  Make certain automated tasks possible.

But, this time, sshd still prompted for a password.  I checked a lot of stuff.  Then I googled and I discovered that SELinux was probably blocking me.  By reading a bit on The UnOfficial SELinux FAQ and then reading some man pages and then googleing more intelligently, I eventually learned that along with your standard file system permissions, SELinux enabled systems have this nice method of enforcing which daemons can access which files and such.  Sort of like how we use security groups in Active Directory to regulate access to resources on the Windows Domain.  Much more useful than the old Unix groups.

So, now I know it’s more accurate to describe the situation like this:

SELinux was blocking a daemon from accessing a file in a sensitive area.  Specifically, the .ssh directory and files in it that I created in “account’s” directory aren’t known to the SELinux system.  And since it knows that “account’s” home directory is sensitive – says so in a config file –  it doesn’t know if it should allow sshd to read them or not.

Our current method of setting up private key authentication, copying around the authorized_keys file,  doesn’t include updating that structure so that sshd can access the files.  So, on this SELinux enabled RHEL 6 server, itsa-no-a-go-ah!

Here’s how you can update the SELinux information for the new files: