#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth

Is there anything like pam_selinux(sshd:session): Unable to get valid context for root in the logs?
–
Andrey VoitenkovDec 12 '12 at 9:50

@DeanSchulze Tom meant the one on the client side containing the private keys. You seem to have more than 3 private keys and after 3 attempts it will not be able to continue with more. Specify the one matching with the private one put in authorized_keys file on the remote machine. What happens if you do ssh user@host -o IdentityFile=/home/user/myprivatekey?
–
gertvdijkDec 12 '12 at 13:56

6 Answers
6

I had the same issue after installing Gitlab 6.4 on RHEL 6.5. No matter what i did i could not SSH using public keys for the main system user (git). Again the SSH keys were fine, as were the permissions on ~/.ssh (700) an ~/.ssh/authorized_keys (600). The issue was that seliunx was "enforcing" and the contexts in the .ssh directory were wrong, probably because the user was created as a system user. You could fix as @Dean-Schulze did by changing the user to normal user, but i managed to fix the contexts for the affected user using the restorecon command which may solve the issue you are having.

Check if selinux is enforcing

sestatus

Examine the contexts using

ls -laZ ~/.ssh

I found that the "type" context needed to be "ssh_home_t"

To fix the ssh directory login/su as the affected user and then run

restorecon -R -v ~/.ssh

If that does not work you may need to fix the context on the users home directory

Malfunctioning public keys are usually caused by bad file permissions on the authorized_keys file. Make sure it is chmodded to 644.

I have had this "problem" many times. Problem is not just with permission of file authorized_keys, also permissions of directories ".ssh" and ".." (home directory of user) should be properly set. Problems would have been solved by setting permission like this: 700 to .ssh, at least 754 to ".." and 600 to file authorized_keys:

My authorized_keys file is 600. I added a new user and used the same ssh-copy-id on the same public key file and ssh works for that user. This looks like a restriction on the root user.
–
Dean SchulzeDec 11 '12 at 23:07

You are not "supposed" to ssh as root - but am assuming yo know that anyway. THe reason I mention this is that some distributions try to dissuade you from sshing to root directly. I do no tthink that is the case with CentOS out of the box. I wonder if SeLinux tries to do so at times...

In any event look at the /etc/ssh/sshd_config and see if that has any reasons to cause the behavior you see. Paste it here i yo uwant.

I solved this by adding another user and then changing the Tomcat webapp/ directory to be owned by that regular user. That regular user has no problem authenticating with keys and that user can execute commands via ssh and scp (remote re-deploy to Tomcat).

Another security precaution that RHEL takes is to disable the Tomcat manager application so I can't remote deploy through the Tomcat manager either. (I tried adding the manager application back in and setting up admin and manager users but the manager application wont' run).

It's always a good practice to not use the root user for things like this. Two important notes though. 1) this story about Tomcat should be in the question, 2) it's not an answer to your question, but rather a workaround for your specific needs you didn't mention in the question
–
gertvdijkDec 14 '12 at 21:42

RHEL installs Tomcat with the webapps/ directory with ownership and permissions set so you have to be root to deploy an application. RHEL also installs Tomcat without the manager app, but that is done for security. That's probably something that RedHat should change.
–
Dean SchulzeDec 16 '12 at 19:46

@DeanSchulze I agree with gertvdijk, this is simply a workaround, it doesn't address the core issue: ssh access to root on your server through pki is denying access with no real indication why.
–
Ryan FoleyJan 3 '14 at 11:55