bug in sss_ssh_authorizedkeys

[Franky Van Liedekerke]

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

[Franky Van Liedekerke]

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
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Jan Cholasta]

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 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
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel 

-- 
Jan Cholasta

[Franky Van Liedekerke]

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 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
> >> _______________________________________________
> >> sssd-devel mailing list
> >> sssd-devel(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/sssd-devel

[Jan Cholasta]

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 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
> >>> _______________________________________________
> >>> sssd-devel mailing list
> >>> sssd-devel(a)lists.fedorahosted.org
> >>> https://fedorahosted.org/mailman/listinfo/sssd-devel
> >>
> >> _______________________________________________
> >> sssd-devel mailing list
> >> sssd-devel(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel 

-- 
Jan Cholasta

[Franky Van Liedekerke]

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&gt; 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
>  >>>> _______________________________________________
>  >>>> sssd-devel mailing list
>  >>>> sssd-devel(a)lists.fedorahosted.org
>  >>>> https://fedorahosted.org/mailman/listinfo/sssd-devel
>  >>>
>  >>> _______________________________________________
>  >>> sssd-devel mailing list
>  >>> sssd-devel(a)lists.fedorahosted.org
>  >>> https://fedorahosted.org/mailman/listinfo/sssd-devel
>  >
>  > _______________________________________________
>  > sssd-devel mailing list
>  > sssd-devel(a)lists.fedorahosted.org
>  > https://fedorahosted.org/mailman/listinfo/sssd-devel
>  
>

[Jan Cholasta]

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&gt; 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
> >>>>> _______________________________________________
> >>>>> sssd-devel mailing list
> >>>>> sssd-devel(a)lists.fedorahosted.org
> >>>>> https://fedorahosted.org/mailman/listinfo/sssd-devel
> >>>>
> >>>> _______________________________________________
> >>>> sssd-devel mailing list
> >>>> sssd-devel(a)lists.fedorahosted.org
> >>>> https://fedorahosted.org/mailman/listinfo/sssd-devel
> >>
> >> _______________________________________________
> >> sssd-devel mailing list
> >> sssd-devel(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> >
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel
>  

-- 
Jan Cholasta

[Franky Van Liedekerke]

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&gt; 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

[Jan Cholasta]

Hi,

it might work just fine, but it is a hack, not a proper OpenSSH-LPK 
support implementation. That would require more extensive changes to the 
code and also must not break IPA (which your change does).

If you have an existing OpenSSH-LPK setup, you have to stick with 
ssh-ldap-wrapper, at least until proper OpenSSH-LPK support is 
implemented in SSSD.

Honza

Dne 16.7.2012 11:34, Franky Van Liedekerke napsal(a):
>  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&gt; 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
>
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel 

-- 
Jan Cholasta

[Stephen Gallagher]

On Mon, 2012-07-16 at 14:03 +0200, Jan Cholasta wrote:
>  Hi,
>  
>  it might work just fine, but it is a hack, not a proper OpenSSH-LPK 
>  support implementation. That would require more extensive changes to the 
>  code and also must not break IPA (which your change does).
>  
>  If you have an existing OpenSSH-LPK setup, you have to stick with 
>  ssh-ldap-wrapper, at least until proper OpenSSH-LPK support is 
>  implemented in SSSD. 
We will of course happily accept patches to support the OpenSSH-LPK
implementation. If you would like to take this on, the SSSD team will
help you get it in shape for inclusion.

[Franky Van Liedekerke]

On Mon, 16 Jul 2012 08:11:34 -0400
Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  On Mon, 2012-07-16 at 14:03 +0200, Jan Cholasta wrote:
>  > Hi,
>  > 
>  > it might work just fine, but it is a hack, not a proper OpenSSH-LPK 
>  > support implementation. That would require more extensive changes
>  > to the code and also must not break IPA (which your change does).
>  > 
>  > If you have an existing OpenSSH-LPK setup, you have to stick with 
>  > ssh-ldap-wrapper, at least until proper OpenSSH-LPK support is 
>  > implemented in SSSD.
>  
>  We will of course happily accept patches to support the OpenSSH-LPK
>  implementation. If you would like to take this on, the SSSD team will
>  help you get it in shape for inclusion. 
Well, my c-code is a little rusty, but if the changes are limited, I
can for sure try ...

Franky

[Stephen Gallagher]

On Mon, 2012-07-16 at 20:50 +0200, Franky Van Liedekerke wrote:
>  On Mon, 16 Jul 2012 08:11:34 -0400
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  
>  > On Mon, 2012-07-16 at 14:03 +0200, Jan Cholasta wrote:
>  > > Hi,
>  > > 
>  > > it might work just fine, but it is a hack, not a proper OpenSSH-LPK 
>  > > support implementation. That would require more extensive changes
>  > > to the code and also must not break IPA (which your change does).
>  > > 
>  > > If you have an existing OpenSSH-LPK setup, you have to stick with 
>  > > ssh-ldap-wrapper, at least until proper OpenSSH-LPK support is 
>  > > implemented in SSSD.
>  > 
>  > We will of course happily accept patches to support the OpenSSH-LPK
>  > implementation. If you would like to take this on, the SSSD team will
>  > help you get it in shape for inclusion.
>  
>  Well, my c-code is a little rusty, but if the changes are limited, I
>  can for sure try ...
>   
I'd recommend reading
https://fedorahosted.org/sssd/wiki/Contribute
and
https://fedorahosted.org/sssd/wiki/DevelTutorials

to help you get started. The dev team hangs around in #sssd on
irc.freenode.net as well, if you want to ask questions of us directly.