View Issue Details

IDProjectCategoryView StatusLast Update
0004959CentOS-6selinux-policypublic2011-11-04 15:14
Reporteradip Assigned To 
Status resolvedResolutionfixed 
Product Version6.0 
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" 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.




2011-07-12 07:27

reporter   ~0012947

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

reporter   ~0012950

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

reporter   ~0012982

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

reporter   ~0013182

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

reporter   ~0013184

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

reporter   ~0013186

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

administrator   ~0013190

imho this entry should be closed: not a bug but OP error.


2011-09-01 16:56

reporter   ~0013191

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

manager   ~0013712

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 user1999 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 user1999 Note Added: 0012983
2011-08-31 06:29 manugraille Note Added: 0013182
2011-08-31 06:47 user1999 Note Added: 0013183
2011-08-31 08:02 manugraille Note Added: 0013184
2011-08-31 08:08 user1999 Note Added: 0013185
2011-08-31 21:48 dmaziuk Note Added: 0013186
2011-09-01 09:04 user1999 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