[SSSD-users] Public ssh key in AD

Davor Vusir davortvusir at gmail.com
Thu Aug 27 06:21:39 UTC 2015


On 2015-08-26 21:36, Lukas Slebodnik wrote:
> 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 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.
>> 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 at client-1 ~]# sss_ssh_authorizedkeys myLoginID
>> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...
>>
>> [myLoginID at 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.
>

Is this the correct procedure?
1.
Logged in as "nonPublicKeyUser" su-ing to root in one terminal:
[root at server-1 ~]# service sssd stop
Redirecting to /bin/systemctl stop  sssd.service
[root at server-1 ~]# rm -f /var/log/sssd/sssd*
[root at server-1 ~]# vi /etc/sssd/sssd.conf
[root at server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm 
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
[root at server-1 ~]#

2.
In another terminal from client-1:
PublicKeyUser at server-1 ~
$ ssh server-1.subdomain.example.org
Enter passphrase for key '/home/PublicKeyUser/.ssh/id_rsa': <- No 
password given. Just pressed <return>.
Password:
Last login: Wed Aug 26 12:56:21 2015 from client-1.subdomain2.example.org
[PublicKeyUser at server-1 ~]$ sss_ssh_authorizedkeys PublicKeyUser
ssh-rsa AAAAB3NzaC1yc2EAAA...
[PublicKeyUser at server-1 ~]$ exit

3.
Back to the first terminal:
[root at server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm 
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
[root at server-1 ~]# sss_ssh_authorizedkeys PublicKeyUser
ssh-rsa AAAAB3NzaC1yc2E...
[root at server-1 ~]#


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

After step 3 above:
[root at server-1 ~]# getent group ct-linuxuberadmins
ct-linuxuberadmins:*:10287220:
[root at server-1 ~]# service sssd stop && rm -Rf /var/lib/sss/db/* && rm 
-Rf /var/lib/sss/mc/* && service sssd start
Redirecting to /bin/systemctl stop  sssd.service
Redirecting to /bin/systemctl start  sssd.service
[root at server-1 ~]# getent group ct-linuxservicesadmins
uuct-gg-linuxservicesadmins:*:10287637:
[root at server-1 ~]#

Regards
Davor

> LS



More information about the sssd-users mailing list