Public storage for public keys

[Simon Wilkinson]

On Monday 14 January 2002 22:10, Ed Phillips wrote:
> That would be nice... ssh could query the LDAP directory to decide if sshd
> on the server side is who it claims to be, instead of looking in
> ~/.ssh/known_hosts. 

At present we just build a known_hosts file out of the LDAP map at regular 
intervals. It would be nice to have an interface for the ssh client to query 
this directly (perhaps via a helper program, similar to LPRng's filterfile 
function?)

> Very nice... especially for sites where there are  many server keys that 
ssh must verify.
>
> What attribute do you use in your code for storing host public keys in the
> LDAP directory? 

I'm in the process of writing a draft that details what we're doing here. 
Basically we use the 'sshKey' attribute, with an OID out of our enterprise 
space. This attribute contains the public key in the format of the known 
hosts file.

> What class(es) do you use for the "known_hosts" entries
> that hold these attribute values?  

I've defined a supplemental class which we use with the RFC2306 ipHost class.
It's possible that other definitions which don't require organizations to 
have a 2306 based directory structure would be possible (and better!)

> Are these custom-defined
> attributes/classes or has someone already done this and put it in an RFC?

Currently custom defined, although documenting it all is very high up my 
list! I've been asked by a number of people to write all of this up as an 
Internet-Draft, which I'm doing currently.

> I was thinking about the possibilty of putting public keys for users into
> an LDAP directory so that users would be able to use RSA authenticatation
> to login to a server... but insteaf of sshd using ~/.ssh/authorized_keys
> on the server side, it would fetch the user's public key from the
> directory.  Have you tried implementing anything like this?

No. We're using Kerberos for our secure authentication - using LDAP as a 
means of distributing keys was devised as a means of supporting our legacy 
systems.

Cheers,

Simon.