Description of problem: When trying to log in using SSH to a Fedora computer, sshd need to read the local authorized_keys file in order to allow private key (passwordless) authentication. SELinux's targeted policy prevents sshd from reading the file and hence from allowing passwordless logins Version-Release number of selected component (if applicable): 3.6.12-28.fc11 How reproducible: always Steps to Reproduce: 1. enable SELinux tageted policy 2. copy the public key of some user into the ~/.ssh/authorized_keys file of another user 3. ssh from the first user's account to the second user's login Actual results: SSH asks for a password Expected results: SSH should allow the user to log in without requiring a password Additional info: setroubleshoot reports as thus: Summary SELinux is preventing sshd (sshd_t) "read" home_root_t. Detailed Description SELinux denied access requested by sshd. It is not expected that this access is required by sshd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context: unconfined_u:object_r:home_root_t:s0 Target Objects: authorized_keys [ file ] Source: sshd Source Path: /usr/sbin/sshd Port: <Unknown> Host: chen.office.taboola.com Source RPM Packages: openssh-server-5.2p1-2.fc11 Target RPM Packages: Policy RPM: selinux-policy-3.6.12-28.fc11 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: catchall Host Name: chen.office.taboola.com Platform: Linux chen.office.taboola.com 2.6.29.1-111.fc11.x86_64 #1 SMP Fri Apr 24 10:57:09 EDT 2009 x86_64 x86_64 Alert Count: 46 First Seen: Tue 31 Mar 2009 12:09:48 PM IDT Last Seen: Wed 06 May 2009 11:57:22 AM IDT Local ID: 676f5d5d-2d60-425a-88fd-3375cd96cfb7 Line Numbers: Raw Audit Messages : node=chen.office.taboola.com type=AVC msg=audit(1241600242.790:104): avc: denied { read } for pid=10458 comm="sshd" name="authorized_keys" dev=dm-1 ino=845588 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file node=chen.office.taboola.com type=SYSCALL msg=audit(1241600242.790:104): arch=c000003e syscall=2 success=no exit=-13 a0=7fec9b791620 a1=800 a2=1 a3=4000 items=0 ppid=1573 pid=10458 auid=4294967295 uid=0 gid=0 euid=16777216 suid=0 fsuid=16777216 egid=16777216 sgid=0 fsgid=16777216 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
This home directory is badly labeled. restorecon -R -v /home Or where ever the home directory is located. home_root_t is the label of the /home directory Individual directories under /home should be labeled user_home_dir_t The .ssh directory should be labeled user_ssh_home_t
When a new user creates a .ssh directory (for example - using ssh-keygen) - what causes the labeling of the new directory?
The problem here is the whole directory is mislabeled. If the whole directory was labeled incorrectly, I have no idea why. But a user running ssh-keygen in a directory labeled user_home_dir_t will probably not create the directory with the correct label. If you were running restorcond service, it would probably have labeled it correctly. We are working on solutions for users creating random files directories in the homedir and making sure they are labeled correctly.