Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On Mon, 2016-07-18 at 11:42 -0400, Rob Crittenden wrote:
> That I'm not sure. Kai might know.
Since there were several open questions, we discussed that on IRC.
To summarize here: if you want to install a CA that should be trusted by all
applications on a system, you probably shouldn't install into /etc/pki/nssdb any
more.
Instead, you should install to the proper directory below
/etc/pki/ca-trust/source/
and execute update-ca-trust (see the man page).
In addition, if you write an NSS application and you want it to trust (and
distrust) all the CAs that are installed globally on the system, then, after you
init NSS using the usual init APIs, you should execute a call to load the NSS
trust module, which is named libnssckbi.so
The call is
SECMOD_AddNewModule("Builtins", DLL_PREFIX "nssckbi." DLL_SUFFIX, 0, 0);
(the DLL_*FIX symbols are helpful when you need cross platform code)
An example is here: https://hg.mozilla.org/projects/nss/file/tip/cmd/tstclnt/tst
clnt.c#l1312
Note that the libnssckbi.so in the LD search path is a symbolic link, which on
modern systems points to the replacement module from p11-kit-trust.rpm, which
will dynamically give you the trust information that's managed as explained in
the update-ca-trust manual page.
Kai
--
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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
Sumit Bose wrote: On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote: Sumit Bose wrote: On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote: On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: On (16/07/16 10:19), Martin Štefany wrote: 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 Fedora 23 and fedora 24 has the same version of sssd and almost the same version of openssh. I have no idea what coudl broke it it there are not any AVCs. Using debug_level 0x0250 :: For troubleshooting, it would be better to see all debug messages. (debug_level = 0xfff0) Hello Lukas, thanks for replying on this, here are debug_level = 0xfff0 messages ... (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): CERT_VerifyCertificateNow failed [-8179]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040): cert_to_ssh_key failed. -8179 translates to "Peer's certificate issuer is not recognized." (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html). This means the CA certificate which signed the certificate on the Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD. Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb, this might be the reason why you see this with F24. To fix this please either add the needed CA certificates to /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA certificates to validate the Smartcard certificate. I'm working on a fix for SSSD to handle handle this change automatically, but unfortunately it is not ready yet. The client installer should be adding the IPA CA to the system certificate store which should be picked up automagically by OpenSSL and NSS applications. I think I'd start there to see if that happened. The responsibility for this was delegated to p11-kit in 11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected that p11-kit-proxy will be added to /etc/pki/nssdb by default? That I'm not sure. Kai might know. rob -- 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote: > Sumit Bose wrote: > > On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote: > > > On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: > > > > On (16/07/16 10:19), Martin Štefany wrote: > > > > > > > > > > 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 > > > > > > > > > Fedora 23 and fedora 24 has the same version of sssd > > > > and almost the same version of openssh. > > > > I have no idea what coudl broke it it there are not any AVCs. > > > > > > > > > > > > > > Using debug_level 0x0250 :: > > > > > > > > > For troubleshooting, it would be better to see all > > > > debug messages. (debug_level = 0xfff0) > > > > > > Hello Lukas, > > > > > > thanks for replying on this, here are debug_level = 0xfff0 messages > > > > > > > ... > > > > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): > > > CERT_VerifyCertificateNow failed [-8179]. > > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] > > > (0x0040): > > > cert_to_ssh_key failed. > > > > -8179 translates to "Peer's certificate issuer is not recognized." > > (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html). > > This means the CA certificate which signed the certificate on the > > Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD. > > > > Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb, > > this might be the reason why you see this with F24. > > > > To fix this please either add the needed CA certificates to > > /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the > > [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA > > certificates to validate the Smartcard certificate. > > > > I'm working on a fix for SSSD to handle handle this change > > automatically, but unfortunately it is not ready yet. > > The client installer should be adding the IPA CA to the system certificate > store which should be picked up automagically by OpenSSL and NSS > applications. I think I'd start there to see if that happened. The responsibility for this was delegated to p11-kit in 11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected that p11-kit-proxy will be added to /etc/pki/nssdb by default? bye, Sumit > > rob > -- 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
Sumit Bose wrote: On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote: On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: On (16/07/16 10:19), Martin Štefany wrote: 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 Fedora 23 and fedora 24 has the same version of sssd and almost the same version of openssh. I have no idea what coudl broke it it there are not any AVCs. Using debug_level 0x0250 :: For troubleshooting, it would be better to see all debug messages. (debug_level = 0xfff0) Hello Lukas, thanks for replying on this, here are debug_level = 0xfff0 messages ... (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): CERT_VerifyCertificateNow failed [-8179]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040): cert_to_ssh_key failed. -8179 translates to "Peer's certificate issuer is not recognized." (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html). This means the CA certificate which signed the certificate on the Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD. Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb, this might be the reason why you see this with F24. To fix this please either add the needed CA certificates to /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA certificates to validate the Smartcard certificate. I'm working on a fix for SSSD to handle handle this change automatically, but unfortunately it is not ready yet. The client installer should be adding the IPA CA to the system certificate store which should be picked up automagically by OpenSSL and NSS applications. I think I'd start there to see if that happened. rob -- 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On 7/18/2016 9:50 AM, Sumit Bose wrote: On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote: On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: On (16/07/16 10:19), Martin Štefany wrote: 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 Fedora 23 and fedora 24 has the same version of sssd and almost the same version of openssh. I have no idea what coudl broke it it there are not any AVCs. Using debug_level 0x0250 :: For troubleshooting, it would be better to see all debug messages. (debug_level = 0xfff0) Hello Lukas, thanks for replying on this, here are debug_level = 0xfff0 messages ... (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): CERT_VerifyCertificateNow failed [-8179]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040): cert_to_ssh_key failed. -8179 translates to "Peer's certificate issuer is not recognized." (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html). This means the CA certificate which signed the certificate on the Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD. Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb, this might be the reason why you see this with F24. To fix this please either add the needed CA certificates to /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA certificates to validate the Smartcard certificate. Thank you! Fixed for now by putting 'ca_db = /etc/ipa/nssdb' to the [ssh] section of sssd.conf, but CA certificate is actually the one from IPA CA, as this SSH key is generated from my userCertificate. Works like a charm. Kind regards, Martin I'm working on a fix for SSSD to handle handle this change automatically, but unfortunately it is not ready yet. HTH bye, Sumit $ /usr/bin/sss_ssh_authorizedkeys martin Error looking up public keys And try to run strace with sss_ssh_authorizedkeys LS 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote: > On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: > > On (16/07/16 10:19), Martin Štefany wrote: > > > > > > 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 > > > > > Fedora 23 and fedora 24 has the same version of sssd > > and almost the same version of openssh. > > I have no idea what coudl broke it it there are not any AVCs. > > > > > > > > Using debug_level 0x0250 :: > > > > > For troubleshooting, it would be better to see all > > debug messages. (debug_level = 0xfff0) > > Hello Lukas, > > thanks for replying on this, here are debug_level = 0xfff0 messages > ... > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): > CERT_VerifyCertificateNow failed [-8179]. > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040): > cert_to_ssh_key failed. -8179 translates to "Peer's certificate issuer is not recognized." (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html). This means the CA certificate which signed the certificate on the Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD. Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb, this might be the reason why you see this with F24. To fix this please either add the needed CA certificates to /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA certificates to validate the Smartcard certificate. I'm working on a fix for SSSD to handle handle this change automatically, but unfortunately it is not ready yet. HTH bye, Sumit > > > > > > > $ /usr/bin/sss_ssh_authorizedkeys martin > > > Error looking up public keys > > > > > And try to run strace with sss_ssh_authorizedkeys > > > > LS > > 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote: > On (16/07/16 10:19), Martin Štefany wrote: > > > > 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 > > > Fedora 23 and fedora 24 has the same version of sssd > and almost the same version of openssh. > I have no idea what coudl broke it it there are not any AVCs. > > > > > Using debug_level 0x0250 :: > > > For troubleshooting, it would be better to see all > debug messages. (debug_level = 0xfff0) Hello Lukas, thanks for replying on this, here are debug_level = 0xfff0 messages (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [get_client_cred] (0x4000): Client creds: euid[129341] egid[129341] pid[15966]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5617ca096280][18] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [accept_fd_handler] (0x0400): Client connected! (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5617ca096280][18] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5617ca096280][18] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5617ca096280][18] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400): Requested domain [] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400): Parsing name [martin][] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'martin' matched without domain, user is martin (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys] (0x0400): Requesting SSH user public keys for [martin] from [] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5617c96301a0:1:mar...@stefany.eu] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_dp_get_account_msg] (0x0400): Creating request for [stefany.eu][0x1][BE_REQ_USER][1][name=martin] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sbus_add_timeout] (0x2000): 0x5617ca09bb60 (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5617c96301a0:1:mar...@stefany.eu] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sbus_remove_timeout] (0x2000): 0x5617ca09bb60 (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn: 0x5617ca09a300 (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ssh_user_pubkeys_search_next] (0x0400): Requesting SSH user public keys for [mar...@stefany.eu] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x5617ca0a4370 (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x5617ca0a4430 (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ldb] (0x4000): Running timer event 0x5617ca0a4370 "ltdb_callback" (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x5617ca0a4430 "ltdb_timeout" (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ldb] (0x4000): Ending timer event 0x5617ca0a4370 "ltdb_callback" (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x4000): Mssing element, nothing to do. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x4000): Mssing element, nothing to do. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020): CERT_VerifyCertificateNow failed [-8179]. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040): cert_to_ssh_key failed. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040): decode_and_add_base64_data failed. (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [ssh_cmd_done] (0x0020): Fatal error, killing connection! (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [client_destructor] (0x2000): Terminated client [0x5617ca096280][18] (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5617c96301a0:1:mar...@stefany.eu] > > > > $ /usr/bin/sss_ssh_authorizedkeys martin > > Error looking up public keys > > > And try to run strace with sss_ssh_authorizedkeys > > LS 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
On (16/07/16 10:19), Martin Štefany wrote: >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 > Fedora 23 and fedora 24 has the same version of sssd and almost the same version of openssh. I have no idea what coudl broke it it there are not any AVCs. >Using debug_level 0x0250 :: > For troubleshooting, it would be better to see all debug messages. (debug_level = 0xfff0) >$ /usr/bin/sss_ssh_authorizedkeys martin >Error looking up public keys > And try to run strace with sss_ssh_authorizedkeys LS -- 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
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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=c03e 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 '
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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=c03e
> > > > > 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"
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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?
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=c03e 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=c03e 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 t
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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
>
>
> 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=c03e
> > > 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=c03e
> > > 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 tr
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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...
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=c03e 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=c03e 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 B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> 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]] [
Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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=c03e
> 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=c03e
> 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 B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> 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 in
[Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'
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=c03e 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
...
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=c03e 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 B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> 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
signature.asc
Description: This is a digitally signed message part
--
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
