Hi all, About two weeks ago I described my problem: ssh would connect if I supplied a password, but refused to even look at the keys (this based on the access time stamps not getting updated). I mused about permissions.
Michael Evans responded: "The permissions point is valid, IIRC it [sshd] won't even look at the files if they aren't properly secured." Mat Watson added: "I had a similar problem with ssh. Permissions matter." Ted Stern concurred: "Permissions are usually the key problem." John Locke contributed: "Also check the group ownership, and permissions on your client key..." Derek Simkowiak offered an opinion regarding keys and ssh-agent, but later corrected himself (following a comment from Brian; below). None of the files Ralph Sims named (in /etc/default) exist, and the file that can be used to pull in options in the rc.d/init.d script (/etc/sysconfig/sshd) doesn't exist either. Brian Lane suggested finding the configuration file used by the rc.d/init.d script (/etc/ssh/sshd_config) and compare that to the one used by sshd when launched manually. However, both invocations use the same file. The fun began when I tried running /usr/sbin/sshd -dd Guess what? ssh would connect using the keys! My ssh invocation was simply "ssh -x remote-server", run as the user in question. There were several suggestions about environment variables, so I compared /proc/<pid>/environ of the two instances. The only differences were PATH and that one had OPWD where the other had PWD; changing PATH to match made no difference. All right, let's try this: I copied the rc.d/init.d script to /root and then ran it from there. Keys worked. Same script, different directories, different behavior. Same owners, permissions, etc. Except ... # ls -lZ /root/sshd -rwxr-xr-x root root unconfined_u:object_r:admin_home_t:s0 /root/sshd # ls -lZ /etc/rc.d/init.d/sshd -rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/init.d/sshd The selinux contexts are different! The local key file (in this case, on the remote server) is: # ls -lZ ~backup/.ssh/id_rsa -rw------- backup backup-user unconfined_u:object_r:home_root_t:s0 /home/backup/.ssh/id_rsa My conjecture was that, if the selinux contexts don't match, then no go. This is what most of you said, albeit with traditional permissions in mind. Now that I suspected selinux issues, I looked in /var/log/audit/audit.log and found all kinds of goodies therein (I was looking in secure and messages before). Namely, sshd was being denied access to the user's .ssh directory. So, cutting to the chase: # restorecon -Rv ~backup/.ssh restorecon reset . context system_u:object_r:initrc_exec_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset ./known_hosts context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset ./id_rsa.pub context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset ./id_rsa context system_u:object_r:initrc_exec_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset ./authorized_keys context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0 # ls -lZd ~backup/.ssh drwx------ backup backup system_u:object_r:ssh_home_t:s0 /home/backup/.ssh And now I can start sshd with the /etc/rc.d/init.d/sshd script and keys will work from my local system. Backups now run unattended. Thank you, everyone, for pointing me down the correct path to solving this. -- Mike Schuh, Seattle USA http://www.farmdale.com
