On (26/08/15 13:09), Davor Vusir wrote:
On 2015-08-25 20:25, Lukas Slebodnik wrote:
>On (25/08/15 19:35), Davor Vusir wrote:
>>
>>Lukas Slebodnik skrev den 2015-08-25 11:51:
>>>On (22/08/15 15:32), Davor Vusir wrote:
>>>>Jakub Hrozek skrev den 2015-08-20 22:23:
>>>>>quick top-post
>>>>>
>>>>>I'll be on vacacation starting tomorrow and the whole next week. I
hope
>>>>>some of the other sssd developers can help you out.
>>>>>
>>>>>tl;dr the public key should be set in ldap_user_ssh_public_key
>>>>>
>>>>It is.
>>>>
>>>>>See
>>>>>https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
>>>>>for some performance tips.
>>>>>
>>>>Thank you. The tips did make difference.
>>>>
>>>>>Sorry for being terse.
>>>>>
>>>>Not at all.
>>>>
>>>>But I'm really curious about the reasons behind SSSD failing to
retrieve the
>>>>public key when deactivating subdomains_provider. In our case, as we
don't
>>>>have subdomains but forest trusts which SSSD doesn't support,
we've got no
>>>>reason having subdomains_provider activated to enumerate them (the
trusted
>>>>forests). It would be interesting to know why forest trusts are enumerated
in
>>>>the first place.
>>>>
>>>In previous mail, you provided log files from ssh responder, which just tried
>>>to look up cached ssh key in sssd cache
>>>But we would need to see a different log file to confirm whether public ssh
key
>>>was retrieved from LDAP/AD.
>>>
>>>Please:
>>>* clear old log files and sssd cache
>>rm /var/log/sssd/sssd_ad.example.org
>>
>>>* increase debug_level in domain section to 9
>>>* restart sssd
>>service sssd stop && rm -Rf /var/lib/sss/db/* && rm -Rf
/var/lib/sss/mc/* &&
>>service sssd start
>>
>>>* call "getent passwd user_with_ssh_key_in_ad"
>>myloginid:*:10051785:10000513:Davor Vusir:/home/myloginid:/bin/bash
>>
>>>* provide log files from domain section.
>>>
>>I guess that this is the part you are interested in:
>exactly :-)
>
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_get_primary_name]
>>(0x0400): Processing object myLoginID
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>(0x0400): Processing user myLoginID
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>(0x2000): Adding originalDN [CN=Davor
>>Vusir,OU=Admins,OU=CT,DC=ad,DC=example,DC=org] to attributes of [myLoginID].
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>(0x0400): Adding original memberOf attributes to [myLoginID].
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>[sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp
>>[20150817101423.0Z] to attributes of [myLoginID].
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>(0x0400): Adding user principal [myLoginID(a)AD.EXAMPLE.ORG] to attributes of
>>[myLoginID].
>>...
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>[sdap_attrs_add_ldap_attr] (0x2000): Adding sshPublicKey
[c3NoLXJzYSBaPUFaRjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=]
>>to attributes of [myLoginID].
>Ok, the correct ldapt attribute is stored as ssh public key into sssd cache for that
user.
>
>
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>[sdap_attrs_add_ldap_attr] (0x2000): authType is not available for
>>[myLoginID].
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>[sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities
[c3NoLXJzYSBStUFStjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFETEw0MTZHQzFaVFBzVXpjS01Zbm5QSjNaZG1xWUZLTDArQ05adTQyT0U4ZDZKNFlNR1I0YmcwWUpuVFhhRUI1NWRvazJMV2tBKzlka0R5SFFJSzVxVEk4N09rSzZERWxNSGpPVDhESWlvNVVBUGo3Y1BYNGs4TjJYM0VlaS9FM0o3c1pyeDM5bWtZOSsrNkJXRGJMa084VlJOejhFT2JhUVZEK3pUTy9HWUltTmpFWHhwMzVCd3BES2xEa21BdXVud21KK1RNU2RHWWVEaFp6N25Nd0dVTmh2YmloTkU1N3IrcDhXS2MxVExDQW1TN3IyTE9jNWZPaUp4QmVFRENrVHlvamRQWkl1dkZudzBkZ25UMkRuaFBZcXVNeGJSU0F1WVVhYVpVNUFVUWlPQW1HRGlKVG5IVjczYzY0N09xWnJjbktZSTJ1SEJ6R1BGZXA3dWJ6Q2Y=]
>>to attributes of [myLoginID].
>This one is casued by following option
> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
>
>And should not have any effect to ssh <-> sssd integration.
I realized that while going through the log. The attribute is unnecesseraly
cached . Will remove.
>
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]]
>>[sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add
>>lowercased aliases
>>(Tue Aug 25 18:29:50 2015) [sssd[be[ad.example.org]]] [sdap_save_user]
>>(0x0400): Storing info for user myLoginID
>>
>Now you can test with command line utility sss_ssh_authorizedkeys
>wheter ssh responder is correctly configured.
> ("ssh" should be listed in option services; in sssd section)
>If the public key is returned then you need to check
>sshd configuration files for proper integration.
>
>@see more details in man sss_ssh_authorizedkeys
[root@client-1 ~]# sss_ssh_authorizedkeys myLoginID
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
[myLoginID@client-1 ~]# sss_ssh_authorizedkeys myLoginID
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
Seems to work. But as soon as I put "subdomains_provider = none" either sshd
or sssd (I believe it's sssd) bypasses the ssh public key check. It
recognizes that it should check for the password to unlock the private key,
but doesn't care what I'm typing. It solely check for the kerberos password.
Does sss_ssh_authorizedkeys returns public key with "subdomains_provider =
none"?
Please try with empty cache.
As soon as I comment out "subdomains_provider = none" user
accounts with
public key uses this type of authentication only and user accounts with
Kerberos password uses Kerberos authentication only. Which, of course, is the
goal.
I don't expect you to comment on the sshd_config but here are relevant parts
of both sshd_config and sssd.conf. Both "ct-linuxuberadmins" and
"ct-linuxservicesadmins" in sshd_config are AD-groups with corresponding
sudoers-files.
sssd.conf:
[
domain/ad.example.org]
debug_level = 6
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
subdomains_provider = none
# subdomain_enumerate = none
ignore_group_members = True
enumerate = False
ldap_page_size = 1000
ldap_id_mapping = False
ldap_purge_cache_timeout = 0
ldap_user_ssh_public_key = altSecurityIdentities
ldap_use_tokengroups = True
dyndns_update = False
dyndns_update_ptr = False
cache_credentials = true
krb5_store_password_if_offline = true
sshd_config:
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication yes
UsePAM yes
Match Group ct-linuxuberadmins
AuthorizedKeysCommand /bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser svcCTSSHDbind
Match Group ct-linuxservicesadmins
PubkeyAuthentication no
Maybe I'm wrong but you might miss some groups with disabled subdomain_provider.
Please try with empty cache
So sshd will not get to the section with AuthorizedKeysCommand.
LS