Description of problem: If I use ssh-copy-id to configure the authorized_keys file on a remote system, the key doesn't work until the context is corrected. This only seems to happen for the root user - normal users are not affected. "restorecon -v /root/.ssh/authorized_keys" solves the problem. I'm not sure if this is a problem with SELinux or if the script isn't setting the context correctly (if it's the script, we may want to reassign it). ==================== host1: # ssh-copy-id -i ~/.ssh/id_rsa.pub root@host2 # ssh root@host2 host2: # tail messages Feb 18 18:06:03 dhcp243-30 setroubleshoot: SELinux is preventing the sshd from using potentially mislabeled files (authorized_keys). For complete SELinux messages. run sealert -l 4d4d2a21-def3-499d-8c45-582a6ac7cbee # sealert -l 4d4d2a21-def3-499d-8c45-582a6ac7cbee Summary: SELinux is preventing the sshd from using potentially mislabeled files (authorized_keys). Detailed Description: SELinux has denied sshd access to potentially mislabeled file(s) (authorized_keys). This means that SELinux will not allow sshd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want sshd to access this files, you need to relabel them using restorecon -v 'authorized_keys'. You might want to relabel the entire directory using restorecon -R -v ''. Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:admin_home_t:s0 Target Objects authorized_keys [ file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host host2 Source RPM Packages openssh-server-5.1p1-7.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.6-5.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name host2 Platform Linux host2 2.6.29-0.131.rc5.git2.fc11.x86_64 #1 SMP Wed Feb 18 19:24:47 EST 2009 x86_64 x86_64 Alert Count 2 First Seen Mon Feb 18 18:05:58 2041 Last Seen Mon Feb 18 18:05:58 2041 Local ID 4d4d2a21-def3-499d-8c45-582a6ac7cbee Line Numbers Raw Audit Messages node=host2 type=AVC msg=audit(2244841558.584:49): avc: denied { read } for pid=3250 comm="sshd" name="authorized_keys" dev=dm-0 ino=170 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file node=host2 type=SYSCALL msg=audit(2244841558.584:49): arch=c000003e syscall=2 success=no exit=-13 a0=1bbcdf0 a1=800 a2=1 a3=7f55aa3197b0 items=0 ppid=2909 pid=3250 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) ==================== Version-Release number of selected component (if applicable): Rawhide 20090219 selinux-policy-3.6.6-5.fc11 How reproducible: Every time Steps to Reproduce: 1. see above Actual results: Password still required Expected results: No password required Additional info:
Does restorecon -R -v /root change the context on these files?
Yes, running "restorecon -R -v /root" sets the correct context and root can then log in automatically.
We probably need to add /root/.ssh to restorecond.
Fixed in policycoreutils-2.0.62-2.fc11
I am experiencing exactly this bug again in Fedora 14. ssh-copy-id root@fedorabox generates exactly the described errors. Interestingly after fixing it with restorecon it came up after reboot again. This is a fresh Fedora 14 installation.
This happened before in #499343 and #512830 (F11) and apparently keeps popping up. F15 has the same issue. While I can understand that newly created files have to be labelled correctly, I somehow think this should be done automagically. I.e. the user should not have to relabel her files manually. Isn't it possible to somhow inherit SELinux labels, so that ~/.ssh/authorized_keys has the same labels as $HOME?
Yes but this is not something we want. For example we want to only allow root apps like sshd to read ~/.ssh/authorized_keys But not read ~/creditcard.txt In F16, we have new code that should label .ssh correctly when it gets created in a homedir without the user needing to relabel it.
Christian we are trying to prevent sshd from reading every file with the users homedir. The way we do this is to label ~/.ssh/* differently then the rest of the directory. So sshd can read the .ssh directory but not the rest. In F16 now, we actually can catch the user typeing mkdir ~/.ssh and have the proper labeling happen. Before this, the user was responsible for making sure the label was correct. BTW the user is also responsible to make sure the ownership and permission flags are correct also. ssh-copy-id is a problem since it does this for the user, and for a while had the restorecon built in. Now we are asking that it get put back in.
Thanks for replying, Daniel. I understand that proper labelling is paramount for SELinux to function in a secure manner. I was merely stating the obvious, that it's a user-noticable barrier. I'm glad that F16 takes care of the labelling now, as soon as I get my hands on a F16 system I'll try for myself. Thanks again!
There was a bug in ssh-copy-id that has just been fixed, where it will now execute restorecon when it is run.