This question should be asked before, but I fail to find the discussion. What options can be used for storing host/users pubkeys in a publically available places? I know openssh currently provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. But what about many machines? Think of e.g. pgp keyservers. Note that pgp keyservers isn't a good solution *always*. The best one IMHO will be to use a mechanism similar to name service switch (as found on solaris and now on linux/glibc, and on other systems as well). Sometimes, even this nsswitch mechanism can be used directly, by extending it for ssh needs (while nss api is known). There will be private module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, nis, ldap, db etc. Especially useful here is ldap, as it has more and more usages/deployments and was designed to store such kind of information. Even DNS can be used here (trusted, i.e. local, ofcourse)! Can something like this be done? (No, I don't ask to implement such a mechanism, but about possibilities of an "idea")? Regards, Michael.
On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote:> What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? >[...]> > Can something like this be done? (No, I don't ask to implement > such a mechanism, but about possibilities of an "idea")?There is a significant trust problem. You can't store pubkeys in places that are untrustworthy, like DNS, LDAP, unless you sign the keys. Which introduces a bunch of other problems. /fc
On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote:> This question should be asked before, but I fail to find > the discussion. > > What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? > > Think of e.g. pgp keyservers. Note that pgp keyservers isn't > a good solution *always*. The best one IMHO will be to use > a mechanism similar to name service switch (as found on solaris > and now on linux/glibc, and on other systems as well). Sometimes, > even this nsswitch mechanism can be used directly, by extending > it for ssh needs (while nss api is known). There will be private > module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, > nis, ldap, db etc. Especially useful here is ldap, as it has more > and more usages/deployments and was designed to store such kind > of information. Even DNS can be used here (trusted, i.e. local, > ofcourse)!There was a spec to use DNS KEY records written for the secsh wg at one point, but that draft was withdrawn and there is some serious opposition to using DNS KEY records for application keys within DNSEXT. That debate has not yet been resolved. You could use LDAP. SSH is kind of a maverick as far as using OS provided resources for this kind of thing, though. I'm not at all interested in reinventing, say, NIS+. Or even kerberos. -- David Terrell | "the only part about medicinal marijuana that Prime Minister, Nebcorp | bothers me is that, when I started chemo, all of dbt at meat.net | my children and grandchildren told me they could http://wwn.nebcorp.com/ | get some for me if I needed it." -mrw's grandfather
how can you trust ldap? or dns? On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote:> This question should be asked before, but I fail to find > the discussion. > > What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? > > Think of e.g. pgp keyservers. Note that pgp keyservers isn't > a good solution *always*. The best one IMHO will be to use > a mechanism similar to name service switch (as found on solaris > and now on linux/glibc, and on other systems as well). Sometimes, > even this nsswitch mechanism can be used directly, by extending > it for ssh needs (while nss api is known). There will be private > module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, > nis, ldap, db etc. Especially useful here is ldap, as it has more > and more usages/deployments and was designed to store such kind > of information. Even DNS can be used here (trusted, i.e. local, > ofcourse)! > > Can something like this be done? (No, I don't ask to implement > such a mechanism, but about possibilities of an "idea")? > > Regards, > Michael. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
On Mon, 14 Jan 2002, Markus Friedl wrote:> how can you trust ldap?LDAP over TLS could be usable. not very scalable though.> or dns?DNSsec. very scalable. jakob
Jakob Schlyter wrote:> > On Mon, 14 Jan 2002, Markus Friedl wrote: > > > how can you trust ldap? > > LDAP over TLS could be usable. not very scalable though.There is no need to have scalable backend for this sort of things. Regards, Michael.
Markus Friedl wrote:> > how can you trust ldap? or dns?How you can trust public pgp keyservers? On another side, for storing *public* keys, there is no *real* need to be *so* suspicious. Saved pubkeys protects from man-in-the-middle attacks. If a key stored in some other place, that "middle-man" need to break a naming service (e.g. dns) of *target* host *and* your local naming service and/or pubkey storage (depending on how this is organized). Those two breakdowns should happen at the same time as your connection attempt to a target host. Well, it IS possible to research and implement such an attack, but an attacker should be really mad trying to hijaak your data. And in this case, your information should be VERY needed by an attacker -- in this case of so interesting information, extra security layers should be in place anyway, and *untrusted* dns/ldap/whatether should NOT be used for key storage either. A sort of -- I know, there are attackers exists who does their job for fun only for example. But imagine e.g. local dns server that handles local zones (and another one that talks with the world) -- I see no reason to NOT trust this local dns server (if configured properly). After all, if that dns server will be cracked, an intruder probably will be able to change /etc/ or ~/.ssh/ files as well. Regards, Michael.