Hello,
On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas.
What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema?
Regards ML
ML mail wrote:
On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas.
What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema?
Do you already have LDAP entries representing your host/systems? That's really hard part.
If you already have host entries, you can simply add aux object class 'ldapPublicKey' to this entries and put the various host keys (different algorithms) in the multi-valued attribute 'sshPublicKey'.
Ciao, Michael.
Thanks for your reply. That's exactly what I did: use the sshPublicKey attribute from the ldapPublicKey objectClass and it works nicely. I wish this ldapPublicKey objectClass could be included as default into OpenLDAP.
Regards ML
On Wednesday, April 16, 2014 6:46 PM, Michael Ströder michael@stroeder.com wrote: ML mail wrote:
On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas.
What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema?
Do you already have LDAP entries representing your host/systems? That's really hard part.
If you already have host entries, you can simply add aux object class 'ldapPublicKey' to this entries and put the various host keys (different algorithms) in the multi-valued attribute 'sshPublicKey'.
Ciao, Michael.
On 16 Apr 2014, at 19.46, Michael Ströder michael@stroeder.com wrote:
ML mail wrote:
On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas.
What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema?
Do you already have LDAP entries representing your host/systems? That's really hard part.
If you already have host entries, you can simply add aux object class 'ldapPublicKey' to this entries and put the various host keys (different algorithms) in the multi-valued attribute 'sshPublicKey'.
Ciao, Michael.
There doesn’t exist any sort of objectClass named ldapPublicKey in any standard LDAP objectClasses or in any submitted RFCs.
Of course anybody can register an OID with IANA and create their own schema, but it would really be best for the OpenBSD project to publish an SSH LDAP schema under 1.3.6.1.4.1.30155 .
Nobody benefits when people who are not authoritative start publishing schema and OIDs to blog posts and HOWTOs around the net. What eventually ends up happening is that search results turn up multiple schemas assigning different OIDs to the same named objectClasses and attributes, people use them, and the OID, objectClass, and attribute namespaces all go into conflict.There are a lot of people who try to write LDAP schema just to get something working, who have absolutely zero idea of what an OID namespace means. Here in the LDAP world, we live by the IANA assigned namespace so that’s what we need to abide by.
A better strategy would be to model these things with "ObjectClass: extensibleObject” in the short term and wait for something official. That could mean changing your own code to comply with the official objectClass and attribute names sooner or later.
—mike
Mike Jackson wrote:
On 16 Apr 2014, at 19.46, Michael Ströder michael@stroeder.com wrote:
ML mail wrote:
On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas.
What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema?
Do you already have LDAP entries representing your host/systems? That's really hard part.
If you already have host entries, you can simply add aux object class 'ldapPublicKey' to this entries and put the various host keys (different algorithms) in the multi-valued attribute 'sshPublicKey'.
There doesn’t exist any sort of objectClass named ldapPublicKey in any standard LDAP objectClasses or in any submitted RFCs.
It's quite usual nowadays to use this when dealing with SSH keys in LDAP entries:
https://code.google.com/p/openssh-lpk/
The schema file:
http://code.google.com/p/openssh-lpk/source/browse/trunk/schemas/openssh-lpk...
Of course anybody can register an OID with IANA and create their own schema, but it would really be best for the OpenBSD project to publish an SSH LDAP schema under 1.3.6.1.4.1.30155 . Nobody benefits when people who are not authoritative start publishing schema and OIDs to blog posts and HOWTOs around the net. What eventually ends up happening is that search results turn up multiple schemas assigning different OIDs to the same named objectClasses and attributes, people use them, and the OID, objectClass, and attribute namespaces all go into conflict.There are a lot of people who try to write LDAP schema just to get something working, who have absolutely zero idea of what an OID namespace means. Here in the LDAP world, we live by the IANA assigned namespace so that’s what we need to abide by.
Sorry, after 15 years working with LDAP I still assign OIDs from my own OID arc - huhuhu - even when writing I-Ds.
A better strategy would be to model these things with "ObjectClass: extensibleObject” in the short term and wait for something official.
Whatever you mean by "official".
But the worst recommendation you can ever give to someone is to use 'extensibleObject' which disables all schema checking for that entry. That really sucks.
Ciao, Michael.
On 04/16/2014 11:20 AM, Michael Ströder wrote:
It's quite usual nowadays to use this when dealing with SSH keys in LDAP entries:
Found this in sshd_config(5):
*------snip------- AuthorizedKeysCommand* Specifies a program to be used to look up the user's public keys. The program must be owned by root and not writable by group or others. It will be invoked with a single argument of the username being authenticated, and should produce on standard output zero or more lines of authorized_keys output (see AUTHORIZED_KEYS in sshd(8) http://www.openssh.com/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current). If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual *AuthorizedKeysFile* files. By default, no AuthorizedKeysCommand is run ------snip-------
The schema file:
http://code.google.com/p/openssh-lpk/source/browse/trunk/schemas/openssh-lpk...
You would still need a schema like that, though, but at least no patching OpenSSH anymore.
-Stephan
Stephan Fabel wrote:
On 04/16/2014 11:20 AM, Michael Ströder wrote:
It's quite usual nowadays to use this when dealing with SSH keys in LDAP entries:
Found this in sshd_config(5):
*------snip------- AuthorizedKeysCommand* Specifies a program to be used to look up the user's public keys. The program must be owned by root and not writable by group or others. It will be invoked with a single argument of the username being authenticated, and should produce on standard output zero or more lines of authorized_keys output (see AUTHORIZED_KEYS in sshd(8) http://www.openssh.com/cgi-bin/man.cgi?query=sshd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current). If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual *AuthorizedKeysFile* files. By default, no AuthorizedKeysCommand is run ------snip-------
Yes, that would be usable for retrieving authorized keys remotely though I personally prefer to sync SSH authorized keys to a central directory and set AuthorizedKeysFile accordingly.
But I understood the original poster that he wants to generate a known hosts file by retrieving all the *host* keys from LDAP.
Ciao, Michael.
openldap-technical@openldap.org
-
Michael Ströder -
Mike Jackson -
ML mail -
Stephan Fabel