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(a)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(a)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(a)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@default
>>>>>>
>>>>>> Also, fixing algo_len to "7" seemed to have an effect,
but
>>>>>> resulted in another output:
>>>>>> dss AAA c3NoXXXXXXXXX MYUSER@default
>>>>>>
>>>>>>
>>>>>> So, there seems something wrong here, but I can't figure it
>>>>>> out.
>>>>>> Any tips?
>>>>>>
>>>>>> Franky