I thought I'd share this for anyone finding themselves struggling with this in the future, saving themselves a few hours.


My goal was to ssh to system A and land on system B, running CentOS 6.2, as root:

ie: ssh root@systemB:

However, I continued to be prompted for password. I verified several dozen times the permissions were correct on both systems, since I've done this countless times in the past without issue and am familiar with the permissions issues. However, I was still struggling mightily. After trying many combinations and permutations of sshd_config settings, I finally stumbled upon the answer: It was SELinux.
In previous versions of CentOS, one could run:

# setup

And in the Firewall section disable SELinux. However, I didn't see this in 6.2. However, there does exist a file:

/etc/selinux/config

Which by default contains a line:

SELINUX=enforcing

I changed this to:

SELINUX=disabled

And rebooted. ssh then worked using the key auth.

This is in no way a suggestion for people to disable SELinux! I'm simply pointing out the culprit which was giving me so much grief, and causing my connection to fail silently.

I checked the /var/log/audit/audit.log, and saw my IP show up a few times, but wasn't sure what the entries meant:

===
type=CRYPTO_KEY_USER msg=audit(1340053446.926:14781): user pid=1571 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=18:61:6e:22:57:9c:5c:4e:7f:69:12:8a:2b:24:24:39 direction=? spid=1571 suid=0 : exe="/usr/sbin/sshd" hostname=? addr=10.4.3.10 terminal=? res=success'
===

But the fact that 'sshd' was in there was a clue.

Odd thing, after finding this, I went back and set it back to:

SELINUX=enforcing

To see the error again, but now I'm still able to ssh in as originally desired.

If anyone has another solution to permit this connectivity without disabling SELinux, feel free to post. Perhaps the solution is to disable it once, reboot, re-enable it, and you're set!



Cheers!

First, thanks for posting the work around! I cannot stress enough how many times I've actually found solutions to things because people post solutions :-)

A test I would do is that I would check the SELinux contexts on the known_hosts file...maybe when it gets created; the contexts are set incorrectly?

I'd be interesting to see the "ll -Z known_hosts" NOW compared to one that isn't working...

-C

I added another interface to the VM and can now duplicate the issue. When I enable SELinux, I can not ssh as root to the system; when I disable SELinux, I am able to ssh to the system. However, the original interface remains accessible no matter how I set SELinux now.

What specifically would you like me to check?