[SSSD-users] Public ssh key in AD

Lukas Slebodnik lslebodn at redhat.com
Tue Aug 25 18:25:01 UTC 2015


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


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

LS


More information about the sssd-users mailing list