This one really threw me off. I buldt a rhel-6.1 test box, and I couldn’t get in using the root ssh key I loaded into ssh-agent. The `ssh-copy-id` worked fine. However, I was getting prompted for the account password (not my key’s password). Here’s what I saw and here’s how to get around it.
The clue I needed came in the messages file:
... setroubleshoot: SELinux is preventing /usr/sbin/sshd "read" access to authorized_keys. For complete SELinux messages. run sealert -l a2c5981a-546b-4541-bf3e-419b33a07f63How handy is that! An error message with the answer built in. When you run the command, you get…
Summary:
SELinux is preventing /usr/sbin/sshd "read" access to authorized_keys.
Detailed Description:
SELinux denied access requested by sshd. authorized_keys may be a mislabeled.
sshd is allowed to read content in /root/.ssh directory if it is labeled
correctly.
Allowing Access:
You can restore the default system context to this file by executing the
restorecon command. restorecon restore using restorecon -R /root/.ssh.
Fix Command:
/sbin/restorecon -R /root/.sshFirst, I will have to read up on this restorcon and the extended attributes it is acting on, but it doesn’t explain the “.” at the end of the posix permissions.
Second, it’s trying to prevent me from doing something as stupid as remote login as root. Yes, yes, I know. For a temp dev system, to test a condition, on an isolated dev network, I don’t feel so bad.
I ended up following the advice from Red Hat and ran the following:
restorecon -R -v /root
restorecon reset /root/.ssh context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0