CentOS Bug Tracker
CentOS Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004959CentOS-6selinux-policypublic2011-07-12 07:022011-11-04 15:14
Reporteradip 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version6.0 
Target VersionFixed in Version 
Summary0004959: SSH public key authentication doesn't work if selinux mode is Enforcing
DescriptionTested 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 InformationTo 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)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0012947)
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 [^]
(0012949)
wolfy (developer)
2011-07-12 09:39

I've added a line about that in the "known issues" of the release notes.
(0012950)
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.
(0012982)
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 :)
(0012983)
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.
(0013182)
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
(0013183)
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.
(0013184)
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.
(0013185)
wolfy (developer)
2011-08-31 08:08

It also works with selinux enabled when proper contexts are used for the files.
(0013186)
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
(0013189)
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.
(0013190)
tru (administrator)
2011-09-01 10:15

imho this entry should be closed: not a bug but OP error.
(0013191)
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.
(0013712)
toracat (developer)
2011-11-04 15:14

As stated by tru, this ticket should have been closed much earlier. Now doing it (closing as "resolved").

- 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


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker