[SSSD] bug in sss_ssh_authorizedkeys

Franky Van Liedekerke liedekef at telenet.be
Mon Jul 16 09:34:50 UTC 2012


Hi,

ok, but then the question remains:

with the small change I've done, it seems to work just fine for reading 
openssh keys from ldap and returning them to sshd as expected.
If the code currently supports only IPA, it seems that with a small 
change it then supports openssh-lpk keys just fine then also, no? Or is 
this not the intention and are people expected to switch to the new 
format (which would be very cumbersome for transition scenarios)?

Franky

On 2012-07-16 11:15, Jan Cholasta wrote:
> Hi,
>
> that's because the output of sss_ssh_authorizedkeys is generated
> using this code, so it is always executed.
>
> Honza
>
> Dne 13.7.2012 20:11, Franky Van Liedekerke napsal(a):
>> If that is the case, why am I entering that code section when 
>> reading
>> keys from LDAP? Maybe it is not the intention, but
>> sss_ssh_authorizedkeys.c uses that section.
>>
>> Franky
>>
>> On Fri, 13 Jul 2012 17:22:18 +0200
>> Jan Cholasta <jcholast at redhat.com> wrote:
>>
>>> This code is for writing public keys, not for reading them from 
>>> LDAP.
>>>
>>> Dne 13.7.2012 17:18, Franky Van Liedekerke napsal(a):
>>>> That seems weird to me, as the code clearly specifies
>>>>
>>>> "case SSS_SSH_FORMAT_RAW:"
>>>> and
>>>> "case SSS_SSH_FORMAT_OPENSSH:"
>>>>
>>>> in src/util/sss_ssh.c
>>>> And everywhere else SSS_SSH_FORMAT_OPENSSH is used as the format
>>>> (doesn't seem to be possible to change this via an option).
>>>> So imho the code does support it just fine (as I've proven with my
>>>> little patch), but has been incorrectly adapted to work for base64
>>>> encoded keys while the format stays SSS_SSH_FORMAT_OPENSSH.
>>>> My guess is: the format should be made configurable and then for
>>>> openssh just return what's in ldap ...
>>>>
>>>> Franky
>>>>
>>>> On 2012-07-13 16:55, Jan Cholasta wrote:
>>>>> Hi,
>>>>>
>>>>> you have the public keys in LDAP in wrong format. SSSD SSH 
>>>>> support
>>>>> is currently limited only to IPA, which stores only the raw 
>>>>> public
>>>>> key blob (see RFC 4253 section 6.6), as opposed to OpenSSH-LPK,
>>>>> which stores public keys in OpenSSH format ("[options] <public 
>>>>> key
>>>>> algorithm
>>>>> name> <base-64 encoded raw public key blob> [comment]", see
>>>>> name> sshd(8)).
>>>>>
>>>>> So, you can either have public keys in LDAP in IPA format (you 
>>>>> can
>>>>> set them using "ipa user-mod" and "ipa host-mod" commands) and 
>>>>> use
>>>>> SSSD to provide the OpenSSH-LDAP link, or you can have public 
>>>>> keys
>>>>> in LDAP in OpenSSH format and use ssh-ldap-wrapper to provide the
>>>>> OpenSSH-LDAP link. Anything else is not supported ATM.
>>>>>
>>>>> Honza
>>>>>
>>>>> Dne 13.7.2012 15:25, liedekef at telenet.be napsal(a):
>>>>>> Btw,
>>>>>>
>>>>>> I managed to get things working by making sure the function
>>>>>> "sss_ssh_format_pubkey" just returns the value of the found
>>>>>> public key, not base64 encoded (which it should not be for
>>>>>> openssh formatted keys). So there the "return pubkey->data"
>>>>>> statement worked just fine, skipping the whole
>>>>>> sss_ssh_get_pubkey_algorithm logic and all. I wonder why the
>>>>>> pubkey algoritm should be searched for anyway, ssh is capable of
>>>>>> interpreting this all by itself.
>>>>>>
>>>>>> Franky
>>>>>>
>>>>>> On 2012-07-13 15:10, liedekef at telenet.be wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to use the experimental feature
>>>>>>> "sss_ssh_authorizedkeys" on a up-to-date fedora 17. Now it 
>>>>>>> seems
>>>>>>> everytime I call that binary, it returns the non-descriptive
>>>>>>> error "Not enough memory". Using my basic C-skills, I 
>>>>>>> downloaded
>>>>>>> the latest SSSD sources (1.8.4) and recompiled them myself: the
>>>>>>> result was the same. Adding some print-statements, I stumbled
>>>>>>> upon this function sss_ssh_get_pubkey_algorithm in
>>>>>>> src/util/sss_ssh.c:
>>>>>>>
>>>>>>> char *
>>>>>>> sss_ssh_get_pubkey_algorithm(TALLOC_CTX *mem_ctx,
>>>>>>>                               struct sss_ssh_pubkey *pubkey)
>>>>>>> {
>>>>>>>      size_t c = 0;
>>>>>>>      uint32_t algo_len;
>>>>>>>      char *algo;
>>>>>>>
>>>>>>>      SAFEALIGN_COPY_UINT32(&algo_len, pubkey->data, &c);
>>>>>>>      algo_len = ntohl(algo_len);
>>>>>>>
>>>>>>>      algo = talloc_zero_array(mem_ctx, char, algo_len+1);
>>>>>>>      if (!algo) {
>>>>>>>          return NULL;
>>>>>>>      }
>>>>>>>
>>>>>>>      memcpy(algo, pubkey->data+c, algo_len);
>>>>>>>
>>>>>>>      return algo;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> ==> it seems I always end up in the "return NULL" statement,
>>>>>>> which seems very weird to me. Current SSH setups can get their
>>>>>>> authorized keys from LDAP just fine (using 
>>>>>>> "AuthorizedKeysCommand
>>>>>>> /usr/libexec/openssh/ssh-ldap-wrapper" in sshd_config), so my
>>>>>>> keys are just fine in LDAP.
>>>>>>> I believe the call to SAFEALIGN_COPY_UINT32 is either wrong or
>>>>>>> has the wrong arguments, since algo_len is a bizare huge
>>>>>>> number ... Trying to change the
>>>>>>>     return NULL
>>>>>>> in
>>>>>>>     return "ssh-dss
>>>>>>> resulted in better effects (but still my key wasn't being
>>>>>>> accepted, maybe another issue). The result (a bit obfuscated):
>>>>>>>
>>>>>>> ./sss_ssh_authorizedkeys MYUSER
>>>>>>> ssh-dss c3NoXXXXXXXXX MYUSER at default
>>>>>>>
>>>>>>> Also, fixing algo_len to "7" seemed to have an effect, but
>>>>>>> resulted in another output:
>>>>>>> dss AAA c3NoXXXXXXXXX MYUSER at default
>>>>>>>
>>>>>>>
>>>>>>> So, there seems something wrong here, but I can't figure it 
>>>>>>> out.
>>>>>>> Any tips?
>>>>>>>
>>>>>>> Franky




More information about the sssd-devel mailing list