2016-10-21 18:23 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004959CentOS-6selinux-policypublic2011-11-04 15:14
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




adip (reporter)

Apparently this is an upstream bug (or "feature"?):


wolfy (developer)

I've added a line about that in the "known issues" of the release notes.


adip (reporter)

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)

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)

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)

The bug also occurs when SeLinux is in DISABLED mode.
It's very annoying for people d'ont wanting to activate selinux


wolfy (developer)

The bug CANNOT occur if selinux is disabled. You have another issue which might look similar but is different.


manugraille (reporter)

Sorry, after reading again my authorized_keys file, i left an extra characters in it.
I confirm that work with elinux disabled.


wolfy (developer)

It also works with selinux enabled when proper contexts are used for the files.


dmaziuk (reporter)

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)

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)

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


dmaziuk (reporter)

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 (developer)

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
+Issue History