I used ssh-copy-id to copy my public key over to a Fedora 11 system. Public key authentication did not work after I did that. I ended up discovering that selinux was to blame for it not working. After doing a: restorecon -Rv ~/.ssh/ ssh public key authentication worked. No messages were found in /var/log/secure indicating an selinux issue.
John, does sshd create the ~/.ssh directory for you? Or did you do it yourself?
Destination system (one with selinux issue) is a fresh install with no ~/.ssh/. Then on my desktop system I use ssh-copy-id to copy my public key to the destination system. So I assume that ssh-copy-id takes care of creating the ~/.ssh/ directory and copying the file to the destination system.
Did you see an AVC indicating sshd tried to create a directory in the homedir. Miroslav, It looks like we need to add # ssh servers can read the user keys and config manage_dirs_pattern(ssh_server, home_ssh_t, home_ssh_t) manage_files_pattern(ssh_server, home_ssh_t, home_ssh_t) userdom_user_home_dir_filetrans(ssh_server, home_ssh_t, dir)
The destination system is one that I am only connecting to via SSH. So all I looked at was the /var/log/secure file and /var/log/messages. So I didn't see any AVC messages since the destination system is running in text mode.
Look in /var/log/audit/audit.log
I see these lines in audit.log: type=1400 audit(1253328372.324:4): avc: denied { read } for pid=2751 comm="sshd" name="authorized_keys" dev=dm-0 ino=140500 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file type=1400 audit(1253328372.324:5): avc: denied { read } for pid=2751 comm="sshd" name="authorized_keys" dev=dm-0 ino=140500 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
Ok these are sshd reading mislabeled files under /root/.ssh But not creating them. Did you use ssh to create the directory under /root?
Maybe I am being dense here. But I used "ssh-copy-id" see: "man ssh-copy-id" for more details. That is what I used to copy my ssh public key and it takes care of creating the ~/.ssh/ directory on the destination system. I deleted ~/.ssh/ on the destination system. Then re-ran ssh-copy-id and then logged in. The messages in Comment 6 are the only ones I saw in my log file.
Well I added the policy above to Rawhide and it works properly now. Miroslav you need # ssh servers can create and read the user keys and config manage_dirs_pattern(ssh_server, home_ssh_t, home_ssh_t) manage_files_pattern(ssh_server, home_ssh_t, home_ssh_t) userdom_user_home_dir_filetrans(ssh_server, home_ssh_t, dir) userdom_admin_home_dir_filetrans(ssh_server, home_ssh_t, dir)
Fixed in selinux-policy-3.6.12-84.fc11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping