Bug 716957 - cannot use public key auth when sshing to host
Summary: cannot use public key auth when sshing to host
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-27 14:57 UTC by Andrew Jones
Modified: 2011-07-25 13:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-25 13:20:56 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.