CentOS Bug Tracker - CentOS-6
View Issue Details
0004959CentOS-6selinux-policypublic2011-07-12 07:022011-11-04 15:14
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= 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= 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

2011-07-12 07:27   
Apparently this is an upstream bug (or "feature"?):
2011-07-12 09:39   
I've added a line about that in the "known issues" of the release notes.
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.
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 :)
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.
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
2011-08-31 06:47   
The bug CANNOT occur if selinux is disabled. You have another issue which might look similar but is different.
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.
2011-08-31 08:08   
It also works with selinux enabled when proper contexts are used for the files.
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
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.
2011-09-01 10:15   
imho this entry should be closed: not a bug but OP error.
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.
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
2011-07-12 07:02adipNew Issue
2011-07-12 07:27adipNote Added: 0012947
2011-07-12 09:39wolfyNote Added: 0012949
2011-07-12 10:44adipNote Added: 0012950
2011-07-15 02:22TimGroeneveldNote Added: 0012982
2011-07-15 07:40wolfyNote Added: 0012983
2011-08-31 06:29manugrailleNote Added: 0013182
2011-08-31 06:47wolfyNote Added: 0013183
2011-08-31 08:02manugrailleNote Added: 0013184
2011-08-31 08:08wolfyNote Added: 0013185
2011-08-31 21:48dmaziukNote Added: 0013186
2011-09-01 09:04wolfyNote Added: 0013189
2011-09-01 10:15truNote Added: 0013190
2011-09-01 16:56dmaziukNote Added: 0013191
2011-11-04 15:14toracatNote Added: 0013712
2011-11-04 15:14toracatStatusnew => resolved
2011-11-04 15:14toracatResolutionopen => fixed