Hi, I've been kicking this idea around, and the problem with it escapes me. I'm looking for someone to tell me why this is a bad idea. The new OpenSSH includes the AuthorizedKeysCommand, which was mostly added to let people use a command to look up user keys in LDAP. LDAP key lookup have some limitations -- specifically, the common openssh-lpk_openldap schema won't let you add restrictions at the front of the key. This didn't matter so much when the LPK patch was such a pain, but now that OpenSSH can actually do this out of the box I'd like to use it. So: What about using a SQLite database, copied to all machines, and a simple sqlite lookup for AuthorizedKeysCommand? If a user can't log into the local machine, because PAM or no local account or whatever, the presence of the key shouldn't matter. For key adds/changes/deletions, I just push the new sqlite DB to all my machines. This seems easy. Too easy. What am I missing? Thanks, ==ml -- Michael W. Lucas - mwlucas at michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code "ILUVMICHAEL" gets you 30% off & helps me.
On Wed, Jun 19, 2013 at 04:26:39PM +0200, ?ngel Gonz?lez wrote:> On 19/06/13 16:10, Michael W. Lucas wrote: > > So: > > > > What about using a SQLite database, copied to all machines, and a > > simple sqlite lookup for AuthorizedKeysCommand? > > > > If a user can't log into the local machine, because PAM or no local > > account or whatever, the presence of the key shouldn't matter. > > > > For key adds/changes/deletions, I just push the new sqlite DB to all > > my machines. > > > > This seems easy. Too easy. What am I missing? > > > > Thanks, > > ==ml > That should work. What makes you think that it wouldn't?Because after two decades of systems administration, I've seen too many people say "Oh, I'll just do this" without being aware of all the implications. It seems that if it was that simple, someone would have done it already... ==ml -- Michael W. Lucas - mwlucas at michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code "ILUVMICHAEL" gets you 30% off & helps me.
On 19/06/13 16:10, Michael W. Lucas wrote:> So: > > What about using a SQLite database, copied to all machines, and a > simple sqlite lookup for AuthorizedKeysCommand? > > If a user can't log into the local machine, because PAM or no local > account or whatever, the presence of the key shouldn't matter. > > For key adds/changes/deletions, I just push the new sqlite DB to all > my machines. > > This seems easy. Too easy. What am I missing? > > Thanks, > ==mlThat should work. What makes you think that it wouldn't?
On Wed, Jun 19, 2013 at 10:10:28AM -0400, Michael W. Lucas wrote:> LDAP key lookup have some limitations -- specifically, the common > openssh-lpk_openldap schema won't let you add restrictions at the > front of the key. This didn't matter so much when the LPK patch was > such a pain, but now that OpenSSH can actually do this out of the box > I'd like to use it.Why use this schema, if it doesn't do what you want? With the latest version of OpenSSH you can pick your own ldapsearch command and so do any schema you like. You could even have the keys attached to the same dn as the existing account object, if you wanted.> This seems easy. Too easy. What am I missing?Scalability, atomicity. Local databases do work (see seos/eTrust AC/Control Minder/name-of-the-day) but a "push" model has performance issues. A notification based pull model scales better. Handling the edge cases (server down; slow to respond; etc) is where the fun starts in your model :-) -- rgds Stephen
On 2013-06-19 at 10:10 -0400, Michael W. Lucas wrote:> What about using a SQLite database, copied to all machines, and a > simple sqlite lookup for AuthorizedKeysCommand? > > If a user can't log into the local machine, because PAM or no local > account or whatever, the presence of the key shouldn't matter. > > For key adds/changes/deletions, I just push the new sqlite DB to all > my machines. > > This seems easy. Too easy. What am I missing?It's easier than that: you don't need an SQLite DB or AuthorizedKeysCommand support. Once you already have all of the infrastructure to control which keys exist for which users, you can manage a directory with files named for the user and N keys per file. Then you can deploy that with puppet/chef/rsync/whatever. In sshd_config you just set: AuthorizedKeysFile /opt/mycompany/etc/sshkeys/%u This works, and has worked, for years, minimizes complexity at login time, makes audit easy and generally is something I've seen used, or have set up, in many places for at least a decade (with patches to pre-openssh sshd, originally). -Phil