[Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
Martin Štefany
martin at stefany.eu
Sat Jul 16 08:19:19 UTC 2016
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 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...
>>>
>>> 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
More information about the Freeipa-users
mailing list