Bug 716957

Summary: cannot use public key auth when sshing to host
Product: Red Hat Enterprise Linux 6 Reporter: Andrew Jones <drjones>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2CC: dwalsh, mmalik, sebastian.koehler
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-25 13:20:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andrew Jones 2011-06-27 14:57:57 UTC
This is a similar problem to that reported in bug 575203.

If sshd is started without using rc-scripts then it works, but if it is started with rc-scripts and enforcing is on, then you cannot login without a password, even if the public key is in authorized_keys.

Setting enforcing off enables it to work.

Comment 2 Miroslav Grepl 2011-06-28 09:01:21 UTC
Andrew,
what AVC msgs are you getting in permissive mode?

Comment 3 Daniel Walsh 2011-06-28 10:38:39 UTC
restorecon -R -v .ssh

Comment 4 Sebastian Koehler 2011-07-23 11:17:20 UTC
Can confirm that it public key login works when restorecon -R -v .ssh is used.

Comment 5 Sebastian Koehler 2011-07-23 11:33:20 UTC
Here are some additional tests I've performed. .ssh/authorized_keys has been created using ssh-copy-id from a remote host. In enforcing mode, login is not possible until restorecon -R -v .ssh is involved.

[root@CentOS ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
[root@CentOS ~]# secon --file .ssh/authorized_keys
user: unconfined_u
role: object_r
type: admin_home_t
sensitivity: s0
clearance: s0
mls-range: s0
[root@CentOS ~]# restorecon -R -v .ssh
restorecon reset /root/.ssh context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:home_ssh_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:home_ssh_t:s0
[root@CentOS ~]# secon --file .ssh/authorized_keys
user: system_u
role: object_r
type: ssh_home_t
sensitivity: s0
clearance: s0
mls-range: s0

If I delete the .ssh directory and recreate it as mentioned above in permissive mode everything is working. The issue is related to the security context of the files created by sshd.

[root@CentOS ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 24
Policy from config file:        targeted
[root@CentOS ~]# secon --file .ssh/authorized_keys
user: unconfined_u
role: object_r
type: admin_home_t
sensitivity: s0
clearance: s0
mls-range: s0

Comment 6 Miroslav Grepl 2011-07-25 13:20:56 UTC
Yes, restorecon is needed.