Bug 466199

It seems that the server for some reasons cannot read the authorized_keys and authorized_keys2 files.
Does it work if you put SELinux into permissive mode?

Putting SELINUX=permissive in /etc/selinux/config fixes the problem; RSA authentication now works.

My success is with openssh sshd in Fedora-10.

Could you try 

'restorecon -r -v -F ~<user>/.ssh'

Did it change any contexts? If so, does it now work in enforcing mode?

Appended is the output from the command.  After running that command, I can now ssh to the host with SELINUX=enforcing.

[root@home etc]# restorecon -r -v -F ~jaffer/.ssh
restorecon reset /home/jaffer/.ssh context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/authorized_keys context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/known_hosts2 context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/known_hosts context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/config context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/authorized_keys2 context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_rsa.pub context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_dsa context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_rsa context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/anoncvs.key context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_dsa.pub context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/random_seed context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0

Dan, what do you think about this problem? This should at least warrant a FAQ entry somewhere. 

I understand that the intent was to not allow sshd to access any files in user and root home dirs except .ssh subdirectory, but I can see that this will get many duplicate bug reports - I've already seen some.

*** This bug has been marked as a duplicate of bug 473014 ***

That the full debug output of ssh gives no hint of why the authentication failed, or even that it did fail, is a bug.

No, not really - actually if it gave a hint it would be a security problem.

Are you saying /var/log/secure or /var/log/messages was not indicating permission denied on  readying of the /home/jaffer/.ssh/  files?

What avc did you actually see?

 | --- Comment #9 from Daniel Walsh <dwalsh>  2009-01-12 15:20:18 EDT ---
 | Are you saying /var/log/secure or /var/log/messages was not indicating
 | permission denied on  readying of the /home/jaffer/.ssh/  files?

/var/log/secure had no indication of the failures; and it didn't occur to me to look in /var/log/messages (which does have indications) for this sort of error.

 | What avc did you actually see?

If AVC is some SELinux thing, then the opportunity to examine it is long gone.  At the time, I had no idea that SELinux was responsible for the failure.

That is strange the sshd/pam would not report permission denied in /var/log/secure?

(In reply to comment #8)
> No, not really - actually if it gave a hint it would be a security problem.

That might be true if sshd behaved consistently with regards to the presence of valid public keys -- but it doesn't.  If "PasswordAuthentication" is "no" in /etc/ssh/sshd_config, then attempts to ssh as users lacking .ssh directories fails immediately, unlike the behavior when there is an .ssh directory but it lacks the requisite permissions on authorized_keys.

Failing immediately or returning a message about permissions would be no more of a  security problem that the behavior above.

There are 2 things mixed up. If the problem is with the .ssh directory on the client side then the ssh -vvv should give hints what the problem is. On the other hand if the problem is with the .ssh directory on the server side, the ssh -vvv can not and should not receive any hints from the server. The ssh server should eventually write something to the /var/log/{secure,messages} on the server.

(In reply to comment #13)
> There are 2 things mixed up. If the problem is with the .ssh directory on the
> client side then the ssh -vvv should give hints what the problem is. On the
> other hand if the problem is with the .ssh directory on the server side, the
> ssh -vvv can not and should not receive any hints from the server. The ssh
> server should eventually write something to the /var/log/{secure,messages} on
> the server.

I am not confusing the client and server sides.  If I ssh to a Fedora10 server having "PasswordAuthentication no" using a username who lacks a .ssh/ directory ON THE SERVER, then it immediately fails:

$ ssh martin
reverse mapping checking getaddrinfo for wireless_broadband_router [xx.xxx.xx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT!
Permission denied (publickey,gssapi-with-mic).

If I ssh to that same Fedora10 server with a username having a misconfigured .ssh/ directory ON THE SERVER, then it takes several minutes to fail.

With "PasswordAuthentication no", sshd violates your claim about not receiving any hints.