[Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

Tue Jun 21 10:43:23 UTC 2016

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 at desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin at desk2 ~]$ sudo setenforce 0
[sudo] password for martin:
[martin at desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin at desk2 ~]$ sudo setsebool nis_enabled on
[martin at desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin at desk2 ~]$ sudo sss_cache -E
[martin at desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys

[have a coffee... really]

[martin at desk2 ~]$ sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa AAA...

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