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 -- 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
