starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #712] Feature request: Allow OpenSSH-LPK schema #254

New issue
Open
opened 2026-02-27 08:16:11 +03:00 by kerem · 12 comments
kerem commented 2026-02-27 08:16:11 +03:00
Owner
Copy link

Originally created by @victoitor on GitHub (Oct 23, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/712

I found nowhere on the code or instructions on how to set up lldap to use OpenSSH-LPK to have OpenSSH use lldap for public key authentication.

Something like this: https://openssh-ldap-pubkey.readthedocs.io/en/latest/openldap.html

Is it possible to do this with lldap? If not, has this been considered?

Originally created by @victoitor on GitHub (Oct 23, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/712 I found nowhere on the code or instructions on how to set up lldap to use OpenSSH-LPK to have OpenSSH use lldap for public key authentication. Something like this: https://openssh-ldap-pubkey.readthedocs.io/en/latest/openldap.html Is it possible to do this with lldap? If not, has this been considered?
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Oct 23, 2023):

Congratulations, you are just in time! It became technically possible
yesterday, after a long period of work on #67 .

However, the web ui doesn't support it yet, so the feature is only
available through direct graphql calls (for now!)
We are looking for volunteers to help debug integrations such as openSSH
and share their configurations.
Could you help us by checking which attributes are necessary to make the
feature work?

On Mon, 23 Oct 2023, 20:53 victoitor, @.***> wrote:

I found nowhere on the code or instructions on how to set up lldap to use
OpenSSH-LPK to have OpenSSH use lldap for public key authentication.

Something like this:
https://openssh-ldap-pubkey.readthedocs.io/en/latest/openldap.html

Is it possible to do this with lldap? If not, has this been considered?

—
Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/712, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWLIEGUQSTEBUJ354STYA24LXAVCNFSM6AAAAAA6MRALCWVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2TOOBRHA3DMOA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

<!-- gh-comment-id:1776095123 --> @nitnelave commented on GitHub (Oct 23, 2023): Congratulations, you are just in time! It became technically possible yesterday, after a long period of work on #67 . However, the web ui doesn't support it yet, so the feature is only available through direct graphql calls (for now!) We are looking for volunteers to help debug integrations such as openSSH and share their configurations. Could you help us by checking which attributes are necessary to make the feature work? On Mon, 23 Oct 2023, 20:53 victoitor, ***@***.***> wrote: > I found nowhere on the code or instructions on how to set up lldap to use > OpenSSH-LPK to have OpenSSH use lldap for public key authentication. > > Something like this: > https://openssh-ldap-pubkey.readthedocs.io/en/latest/openldap.html > > Is it possible to do this with lldap? If not, has this been considered? > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/712>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWLIEGUQSTEBUJ354STYA24LXAVCNFSM6AAAAAA6MRALCWVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2TOOBRHA3DMOA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@levonhart commented on GitHub (Oct 24, 2023):

It seems we need sshPublicKey (repeatable) and the default posixAccount's attributes.

The LDAP ssh key specification:

dn: cn=openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: openssh-lpk
olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DES
 C 'MANDATORY: OpenSSH Public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.
 1.1466.115.121.1.40 )
olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC
  'MANDATORY: OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ 
 uid ) )
<!-- gh-comment-id:1776698019 --> @levonhart commented on GitHub (Oct 24, 2023): It seems we need `sshPublicKey` (repeatable) and the default `posixAccount`'s attributes. The LDAP ssh key specification: ``` dn: cn=openssh-lpk,cn=schema,cn=config objectClass: olcSchemaConfig cn: openssh-lpk olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DES C 'MANDATORY: OpenSSH Public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4. 1.1466.115.121.1.40 ) olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC 'MANDATORY: OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ uid ) ) ```
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@victoitor commented on GitHub (Oct 25, 2023):

We're definitely interested in testing this integration with OpenSSH. Btw, @levonhart works with me and is the person who currently has implemented our initial LDAP solution. We're interested in lldap so we'll be testing it soon.

<!-- gh-comment-id:1779490642 --> @victoitor commented on GitHub (Oct 25, 2023): We're definitely interested in testing this integration with OpenSSH. Btw, @levonhart works with me and is the person who currently has implemented our initial LDAP solution. We're interested in lldap so we'll be testing it soon.
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@levonhart commented on GitHub (Oct 26, 2023):

Congratulations, you are just in time! It became technically possible yesterday, after a long period of work on #67 . However, the web ui doesn't support it yet, so the feature is only available through direct graphql calls (for now!) We are looking for volunteers to help debug integrations such as openSSH and share their configurations. Could you help us by checking which attributes are necessary to make the feature work?

So I added the attribute sshPublicKey with the GraphQL API and initial tests showed that openssh-lpk might be is supported, that is, it is possible to use lldap for SSH public key authentication.
Also, it seems adding attributes only works in lowercase. I couldn't find it documented anywhere.
That means that the attribute to add is actually sshpublickey.
It could be useful if we could add the objectClass: ldapPublicKey attribute to the schema, but it is not necessary.

The graphql query to add sshpublickey:

query: 
mutation addLPKAttribute($lpkName: String!,
                         $lpkType: AttributeType!,
                         $lpkIsList: Boolean!,
                         $lpkIsVisible: Boolean!,
                         $lpkIsEditable: Boolean!) {
  addUserAttribute(name: $lpkName,
                   attributeType: $lpkType,
                   isList: $lpkIsList,
                   isVisible: $lpkIsVisible,
                   isEditable: $lpkIsEditable) {
    ok
  }
}

variables:
{
  "lpkName": "sshpublickey",
  "lpkType": "STRING",
  "lpkIsList": true,
  "lpkIsVisible": true,
  "lpkIsEditable": true
}
<!-- gh-comment-id:1780892087 --> @levonhart commented on GitHub (Oct 26, 2023): > Congratulations, you are just in time! It became technically possible yesterday, after a long period of work on #67 . However, the web ui doesn't support it yet, so the feature is only available through direct graphql calls (for now!) We are looking for volunteers to help debug integrations such as openSSH and share their configurations. Could you help us by checking which attributes are necessary to make the feature work? So I added the attribute `sshPublicKey` with the GraphQL API and initial tests showed that openssh-lpk might be is supported, that is, it is possible to use lldap for SSH public key authentication. Also, it seems adding attributes only works in lowercase. I couldn't find it documented anywhere. That means that the attribute to add is actually `sshpublickey`. It could be useful if we could add the `objectClass: ldapPublicKey` attribute to the schema, but it is not necessary. The graphql query to add `sshpublickey`: ``` query: mutation addLPKAttribute($lpkName: String!, $lpkType: AttributeType!, $lpkIsList: Boolean!, $lpkIsVisible: Boolean!, $lpkIsEditable: Boolean!) { addUserAttribute(name: $lpkName, attributeType: $lpkType, isList: $lpkIsList, isVisible: $lpkIsVisible, isEditable: $lpkIsEditable) { ok } } variables: { "lpkName": "sshpublickey", "lpkType": "STRING", "lpkIsList": true, "lpkIsVisible": true, "lpkIsEditable": true } ```
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Oct 26, 2023):

Thanks!
A couple of points that are nice to highlight:

  • attribute names should be case insensitive: we implement that by
    matching on the lowercase version of the attribute. However, it seems that
    we're not lowercasing when creating attributes. We should fix that.
  • Adding custom object classes is planned as part of #67, but not
    implemented yet.

On Thu, Oct 26, 2023 at 12:59 PM Leonardo de Abreu @.***>
wrote:

Congratulations, you are just in time! It became technically possible
yesterday, after a long period of work on #67
https://github.com/lldap/lldap/issues/67 . However, the web ui doesn't
support it yet, so the feature is only available through direct graphql
calls (for now!) We are looking for volunteers to help debug integrations
such as openSSH and share their configurations. Could you help us by
checking which attributes are necessary to make the feature work?

So I added the attribute sshPublicKey with the GraphQL API and initial
tests showed that openssh-lpk might be is supported, that is, it is
possible to use lldap for SSH public key authentication.
Also, it seems adding attributes only works in lowercase. I couldn't find
it documented anywhere.
That means that the attribute to add is actually sshpublickey.
It could be useful if we could add the objectClass: ldapPublicKey
attribute to the schema, but it is not necessary.

The graphql query to add sshpublickey:

query:
mutation addLPKAttribute($lpkName: String!,
$lpkType: AttributeType!,
$lpkIsList: Boolean!,
$lpkIsVisible: Boolean!,
$lpkIsEditable: Boolean!) {
addUserAttribute(name: $lpkName,
attributeType: $lpkType,
isList: $lpkIsList,
isVisible: $lpkIsVisible,
isEditable: $lpkIsEditable) {
ok
}
}

variables:
{
"lpkName": "sshpublickey",
"lpkType": "STRING",
"lpkIsList": true,
"lpkIsVisible": true,
"lpkIsEditable": true
}

—
Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/712#issuecomment-1780892087, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWOGDHNXBCZCRBMDZP3YBI7C7AVCNFSM6AAAAAA6MRALCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQHA4TEMBYG4
.
You are receiving this because you commented.Message ID:
@.***>

--
Valentin Tolmer

<!-- gh-comment-id:1780931871 --> @nitnelave commented on GitHub (Oct 26, 2023): Thanks! A couple of points that are nice to highlight: - attribute names should be case insensitive: we implement that by matching on the lowercase version of the attribute. However, it seems that we're not lowercasing when creating attributes. We should fix that. - Adding custom object classes is planned as part of #67, but not implemented yet. On Thu, Oct 26, 2023 at 12:59 PM Leonardo de Abreu ***@***.***> wrote: > Congratulations, you are just in time! It became technically possible > yesterday, after a long period of work on #67 > <https://github.com/lldap/lldap/issues/67> . However, the web ui doesn't > support it yet, so the feature is only available through direct graphql > calls (for now!) We are looking for volunteers to help debug integrations > such as openSSH and share their configurations. Could you help us by > checking which attributes are necessary to make the feature work? > > So I added the attribute sshPublicKey with the GraphQL API and initial > tests showed that openssh-lpk might be is supported, that is, it is > possible to use lldap for SSH public key authentication. > Also, it seems adding attributes only works in lowercase. I couldn't find > it documented anywhere. > That means that the attribute to add is actually sshpublickey. > It could be useful if we could add the objectClass: ldapPublicKey > attribute to the schema, but it is not necessary. > > The graphql query to add sshpublickey: > > query: > mutation addLPKAttribute($lpkName: String!, > $lpkType: AttributeType!, > $lpkIsList: Boolean!, > $lpkIsVisible: Boolean!, > $lpkIsEditable: Boolean!) { > addUserAttribute(name: $lpkName, > attributeType: $lpkType, > isList: $lpkIsList, > isVisible: $lpkIsVisible, > isEditable: $lpkIsEditable) { > ok > } > } > > variables: > { > "lpkName": "sshpublickey", > "lpkType": "STRING", > "lpkIsList": true, > "lpkIsVisible": true, > "lpkIsEditable": true > } > > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/712#issuecomment-1780892087>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWOGDHNXBCZCRBMDZP3YBI7C7AVCNFSM6AAAAAA6MRALCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQHA4TEMBYG4> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- Valentin Tolmer
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Jan 22, 2024):

Btw, checking in a bit late, did you manage to make it work?

Now there's https://github.com/Zepmann/lldap-cli to help with managing attributes, and we're working on the web UI as well.

<!-- gh-comment-id:1904907156 --> @nitnelave commented on GitHub (Jan 22, 2024): Btw, checking in a bit late, did you manage to make it work? Now there's https://github.com/Zepmann/lldap-cli to help with managing attributes, and we're working on the web UI as well.
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@levonhart commented on GitHub (Jan 25, 2024):

Thanks for checking in. We had some problems with the client side actually and we were doing some internal changes so I put this on hold for a while.

I'll work on it again within a couple of weeks.

<!-- gh-comment-id:1909182551 --> @levonhart commented on GitHub (Jan 25, 2024): Thanks for checking in. We had some problems with the client side actually and we were doing some internal changes so I put this on hold for a while. I'll work on it again within a couple of weeks.
kerem commented 2026-02-27 08:16:11 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Apr 1, 2025):

Out of curiosity, did you get it to work? The custom objectclass works now (but it's applied to every user), though you might prefer to do an attribute presence check (sshPublicKey=*) instead.

<!-- gh-comment-id:2767945001 --> @nitnelave commented on GitHub (Apr 1, 2025): Out of curiosity, did you get it to work? The custom objectclass works now (but it's applied to every user), though you might prefer to do an attribute presence check `(sshPublicKey=*)` instead.
kerem commented 2026-02-27 08:16:12 +03:00
Author
Owner
Copy link

@victoitor commented on GitHub (Apr 2, 2025):

We stopped working on it for quite some time. Right now we're getting back to it but using kanidm instead, Some issues we've had with it before seem to be gone so we're testing it out.

<!-- gh-comment-id:2770991329 --> @victoitor commented on GitHub (Apr 2, 2025): We stopped working on it for quite some time. Right now we're getting back to it but using kanidm instead, Some issues we've had with it before seem to be gone so we're testing it out.
kerem commented 2026-02-27 08:16:12 +03:00
Author
Owner
Copy link

@helmut72 commented on GitHub (May 26, 2025):

The custom objectclass works now (but it's applied to every user)

Is it planned to add an objectclass to individual users? It's not for this topic, but for this one:
https://www.sogo.nu/files/docs/SOGoInstallationGuide.html#_authentication_using_ldap

For LDAP-based sources, SOGo can also automatically determine if it’s a resource if the entry has the CalendarResource objectClass set.

If an objectclass "CalendarResoure" is created and applied to every user, every user becomes a calendar resource for SOGo. Not very useful ;)

<!-- gh-comment-id:2910691385 --> @helmut72 commented on GitHub (May 26, 2025): > The custom objectclass works now (but it's applied to every user) Is it planned to add an objectclass to individual users? It's not for this topic, but for this one: https://www.sogo.nu/files/docs/SOGoInstallationGuide.html#_authentication_using_ldap > For LDAP-based sources, SOGo can also automatically determine if it’s a resource if the entry has the CalendarResource objectClass set. If an objectclass "CalendarResoure" is created and applied to every user, every user becomes a calendar resource for SOGo. Not very useful ;)
kerem commented 2026-02-27 08:16:12 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (May 27, 2025):

No, per-user classes are not planned.

Modeling calendar resources (neither users nor groups) is not in the scope of LLDAP

<!-- gh-comment-id:2911247731 --> @nitnelave commented on GitHub (May 27, 2025): No, per-user classes are not planned. Modeling calendar resources (neither users nor groups) is not in the scope of LLDAP
kerem commented 2026-02-27 08:16:12 +03:00
Author
Owner
Copy link

@helmut72 commented on GitHub (May 27, 2025):

Modeling calendar resources (neither users nor groups) is not in the scope of LLDAP

SOGo just check for an existing objectclass name per-user, in this case CalendarResource. This can be any other objectclass name, but must be of course per-user.

No, per-user classes are not planned.

Thanks for the info.

<!-- gh-comment-id:2911541459 --> @helmut72 commented on GitHub (May 27, 2025): > Modeling calendar resources (neither users nor groups) is not in the scope of LLDAP SOGo just check for an existing objectclass name per-user, in this case CalendarResource. This can be any other objectclass name, but must be of course per-user. > No, per-user classes are not planned. Thanks for the info.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear labels   
backend

   
blocked

   
bug

   
cleanup

   
dependencies

   
docker

   
documentation

   
duplicate

   
enhancement

   
enhancement

   
frontend

   
github_actions

   
good first issue

   
help wanted

   
help wanted

   
integration

   
invalid

   
ldap

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#254
No description provided.