Hello Sumit,
seems that upgrade to F24 broke things again. This time no AVCs, empty
SSSD logs, but same problem: 'Error looking up public keys'.
selinux-policy-3.13.1-191.fc24.3.noarch
selinux-policy-targeted-3.13.1-191.fc24.3.noarch
sssd-1.13.4-3.fc24.x86_64
Using debug_level 0x0250 ::
$ /usr/bin/sss_ssh_authorizedkeys martin
Error looking up public keys
==> sssd_ssh.log <==
(Sat Jul 16 10:15:51 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
Received client version [0].
(Sat Jul 16 10:15:51 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
Offered version [0].
(Sat Jul 16 10:15:51 2016) [sssd[ssh]] [sss_parse_name_for_domains]
(0x0200): name 'martin' matched without domain, user is martin
==> sssd_stefany.eu.log <==
(Sat Jul 16 10:15:51 2016) [sssd[be[stefany.eu]]] [be_get_account_info]
(0x0200): Got request for [0x1][BE_REQ_USER][1][name=martin]
==> sssd_ssh.log <==
(Sat Jul 16 10:15:51 2016) [sssd[ssh]] [decode_and_add_base64_data]
(0x0040): cert_to_ssh_key failed.
(Sat Jul 16 10:15:51 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
decode_and_add_base64_data failed.
Please, any suggestions?
Martin
On 6/22/2016 5:01 PM, Sumit Bose wrote:
On Tue, Jun 21, 2016 at 01:23:11PM +0200, Martin Štefany wrote:
On 6/21/2016 1:16 PM, Sumit Bose wrote:
On Tue, Jun 21, 2016 at 12:43:23PM +0200, Martin Štefany wrote:
Hello Sumit,
putting SELinux to permissive mode and/or enabling nis_enabled seboolean
seemed not help at all. And you are right, my user has userCertificate
(needed for secure libvirtd connection).
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys
[martin@desk2 ~]$ sudo setenforce 0
[sudo] password for martin:
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys
[martin@desk2 ~]$ sudo setsebool nis_enabled on
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys
[martin@desk2 ~]$ sudo sss_cache -E
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys
[have a coffee... really]
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa AAA...
If I understand it correctly you get the same result as on CentOS,
including the unexpected key derived from the certificate, after waiting
for some time? Can you send the sssd_ssh.log with the sequence from
above (if you prefer directly to me) so that I can check why it failed
in the first attempt and later succeeds.
bye,
Sumit
Hi,
yes, now the results are the same, including the originally unexpected key
from certificate, and actual SSH pubkey auth finally works.
I would send you sssd_ssh.log, but it's empty - I have turned off
debug_level sooner, sorry. :(
Isn't it the case that sss_cache -E takes few seconds to actually expire the
cache entries?
sss_cache -E itself should be fast, but the next requests like
sss_ssh_authorizedkeys would need a bit longer because SSSD must now
read fresh data from the server. Nevertheless it should take some
seconds, maybe 10-20 with lots of group-memberships, but note as much as
a coffee break.
bye,
Sumit
Thank you.
Martin
RH bug for selinux-policy:
https://bugzilla.redhat.com/show_bug.cgi?id=1348447
Thank you!
Martin
On 6/21/2016 9:43 AM, Sumit Bose wrote:
On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
Hello all,
I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) systems
while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same IPA
domain. I will appreciate any help whatsoever.
IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with latest
updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
updates.
I started by looking to the journal:
jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc: denied { name_connect
} for pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c000003e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0
Does the user by chance have a certificate added to his entry including
a link to an OCSP responder?
Recent version of SSSD have the ability to generate public ssh-keys from
valid certificates added to the user entry to support the ssh Smartcard
feature (see e.g. the -I option in the ssh man page for details or
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)
While trying to validate thecertificate via OCSP sssd_ssh must connect
to a http server. To allow this setting the 'nis_enabled' SELinux
boolean to true should help.
Nevertheless, since this should work by default, it would be nice if you
can open a bugzilla ticket for the SELinux policy on F23 to allow this
by default.
HTH
bye,
Sumit
...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc: denied { name_connect
} for pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c000003e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
/usr/bin/sss_ssh_authorizedkeys martin failed, status 1
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
available [preauth]
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 144.xxx.xxx.xxx
port 22543 [preauth]
which was weird, because the same key would nicely work elsewhere (on any other
CentOS 7.2 system, while no Fedora 23 system would work as I have figured out)
I have tried putting SELinux into permissive mode, or generating custom module
with custom policy allowing this, but it doesn't help, and even tcpdump capture
doesn't capture anything when such connection to 'somewhere' port 80 is opened.
I moved on to testing the '/usr/bin/sss_ssh_authorizedkeys martin' command.
Fedora 23:
# sss_ssh_authorizedkeys martin
Error looking up public keys
CentOS 7.2:
# sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsox... (???) -->> this is one is not in
LDAP (checked with ldapsearch & ipa user-show martin --all --raw), not present
in dc=stefany,dc=eu tree or in compat tree
So, I have turned on debug_level = 0x0250 in sssd.conf in both Fedora 23 and
CentOS 7.2 and checked the logs. CentOS 7.2 is just fine, Fedora 23 gives these
failures:
==> /var/log/sssd/sssd_ssh.log <==
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received
client version [0].
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered
version [0].
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200):
name 'martin' matched without domain, user is martin
==> /var/log/sssd/sssd_stefany.eu.log <==
(Mon Jun 20 21:58:14 2016) [sssd[be[stefany.eu]]] [be_get_account_info]
(0x0200): Got request for [0x1][BE_REQ_USER][1][name=martin]
==> /var/log/sssd/sssd_ssh.log <==
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
cert_to_ssh_key failed.
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
decode_and_add_base64_data failed.
And that's right, the last - ghost - "sshpubkey" is invalid base64 string. So
Fedora 23 fails because of some extra validation in SSSD...
I can't tell where this invalid base64 stuff is coming from, and yes, I have
stopped both IPA servers, run sss_cache -E on both of them and on clients, and
started IPA servers serially one by one, the invalid key is still there.
I have a plan B to delete the account, put it back and see if it cleans up, but
I would prefer to figure out what is actually wrong here and what's introducing
the wrong sshpubkey. And why is sssd_ssh connecting to some port 80 somewhere
Thank you in advance!
Kind regards,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
--
Martin
--
--
Martin
--
--
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
