| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0004959 | CentOS-6 | selinux-policy | public | 2011-07-12 07:02 | 2011-11-04 15:14 | ||||
| Reporter | adip | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 6.0 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0004959: SSH public key authentication doesn't work if selinux mode is Enforcing | ||||||||
| Description | Tested on two x86_64 fresh installed systems. One physical server, one running as VM under KVM. Before and after applying the updates from the official CentOS 6 updates repository I'm seeing the following behaviour: - if running in Enforcing mode, ssh authentication using public keys isn't working, the server just ignores all the keys sent by the client - if running in Permissive mode, it's all good, I can do key-based authentication. Apparently sshd has problems accessing /root/.ssh/authorized_keys and I'm seeing entries like this in audit.log: type=USER_LOGIN msg=audit(1310453122.733:300): user pid=1705 uid=0 auid=0 ses=19 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=59.167.195.219 terminal=sshd res=failed' type=USER_ERR msg=audit(1310453147.012:301): user pid=1705 uid=0 auid=0 ses=19 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:bad_ident acct="?" exe="/usr/sbin/sshd" hostname=eth3548.vic.adsl.internode.on.net addr=59.167.195.219 terminal=ssh res=failed' type=AVC msg=audit(1310453152.344:302): avc: denied { read } for pid=1708 comm="sshd" name="authorized_keys" dev=dm-0 ino=787594 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file type=SYSCALL msg=audit(1310453152.344:302): arch=c000003e syscall=2 success=no exit=-13 a0=7f983aa5a090 a1=800 a2=1 a3=7fff30c003b0 items=0 ppid=1601 pid=1708 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=19 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) | ||||||||
| Additional Information | To reproduce: set up public key authentication on a CentOS 6 server, make sure selinux mode is Enforcing and try to authenticate after copying the public key on the server (e.g. using ssh-copy-id) | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
adip (reporter) 2011-07-12 07:27 |
Apparently this is an upstream bug (or "feature"?): http://www.mail-archive.com/linux-390@vm.marist.edu/msg58510.html |
|
wolfy (developer) 2011-07-12 09:39 |
I've added a line about that in the "known issues" of the release notes. |
|
adip (reporter) 2011-07-12 10:44 |
Thanks Wolfy, at least the user has now access to sufficient information to find the root cause of the issue and apply a workaround. There's probably nothing CentOS team can do to fix this if the upstream decides to shove it under the carpet, I reckon. |
|
TimGroeneveld (reporter) 2011-07-15 02:22 |
I can confirm that running the command: restorecon -R -v /root/.ssh or restorecon -R -v ~$USER/.ssh "fixes" this issue. I believe this is due to the policy in /etc/selinux/targeted/contexts/users/root Either way - this is an upstream issue, and I believe we should close this ticket. Also, running restorecond will automatically restore the context of this folder should you create these files be created :) |
|
wolfy (developer) 2011-07-15 07:40 |
For what is worth, ssh-copy-id includes ( since C6 ): { eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys; test -x /sbin/restorecon && /sbin/restorecon .ssh .ssh/authorized_keys" || exit 1 For the selinux illiterate: the files (mind that directories are also files !) modified by the command have their selinux context properly set to the correct value. |
|
manugraille (reporter) 2011-08-31 06:29 |
The bug also occurs when SeLinux is in DISABLED mode. It's very annoying for people d'ont wanting to activate selinux |
|
wolfy (developer) 2011-08-31 06:47 |
The bug CANNOT occur if selinux is disabled. You have another issue which might look similar but is different. |
|
manugraille (reporter) 2011-08-31 08:02 |
Sorry, after reading again my authorized_keys file, i left an extra characters in it. I confirm that work with elinux disabled. |
|
wolfy (developer) 2011-08-31 08:08 |
It also works with selinux enabled when proper contexts are used for the files. |
|
dmaziuk (reporter) 2011-08-31 21:48 |
More data (fresh install), this is from /var/log/secure: Aug 31 09:31:31 cowfish sshd[5777]: pam_selinux(sshd:session): conversation failed Aug 31 09:31:31 cowfish sshd[5777]: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N ] Aug 31 09:31:31 cowfish sshd[5777]: pam_selinux(sshd:session): Unable to get valid context for root Aug 31 09:31:31 cowfish sshd[5777]: pam_unix(sshd:session): session opened for user root by (uid=0) Aug 31 09:33:43 cowfish login: pam_unix(login:session): session closed for user root |
|
wolfy (developer) 2011-09-01 09:04 |
dmaziuk: you have not provided enough information so I have no idea what specific situation triggered the report from your logs but it cannot be due to the initial problem reported as this bug ( #4959 ). A fresh install does not contain any data in the .ssh/* files, so this specific "bug" ( and I used quotes because it is NOT a bug but a known issue -- or change in the policy enforced by upstream) cannot occur. |
|
tru (administrator) 2011-09-01 10:15 |
imho this entry should be closed: not a bug but OP error. |
|
dmaziuk (reporter) 2011-09-01 16:56 |
Oh please. Doesn't everybody copy authorized_keys over to /root/.ssh and set PermitRootLogin to without-password in sshd_config first thing after the initial "remove the cd and reboot"? Don't assume everyone is dumber than you are: I posted it here because the specific situation that produced those log entries was selinux preventing ssh login exactly as described in this bug report. |
|
toracat (manager) 2011-11-04 15:14 |
As stated by tru, this ticket should have been closed much earlier. Now doing it (closing as "resolved"). |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-07-12 07:02 | adip | New Issue | |
| 2011-07-12 07:27 | adip | Note Added: 0012947 | |
| 2011-07-12 09:39 | wolfy | Note Added: 0012949 | |
| 2011-07-12 10:44 | adip | Note Added: 0012950 | |
| 2011-07-15 02:22 | TimGroeneveld | Note Added: 0012982 | |
| 2011-07-15 07:40 | wolfy | Note Added: 0012983 | |
| 2011-08-31 06:29 | manugraille | Note Added: 0013182 | |
| 2011-08-31 06:47 | wolfy | Note Added: 0013183 | |
| 2011-08-31 08:02 | manugraille | Note Added: 0013184 | |
| 2011-08-31 08:08 | wolfy | Note Added: 0013185 | |
| 2011-08-31 21:48 | dmaziuk | Note Added: 0013186 | |
| 2011-09-01 09:04 | wolfy | Note Added: 0013189 | |
| 2011-09-01 10:15 | tru | Note Added: 0013190 | |
| 2011-09-01 16:56 | dmaziuk | Note Added: 0013191 | |
| 2011-11-04 15:14 | toracat | Note Added: 0013712 | |
| 2011-11-04 15:14 | toracat | Status | new => resolved |
| 2011-11-04 15:14 | toracat | Resolution | open => fixed |
| Issue History |
