AuthorizedKeysCommand idea
Ben Lindstrom
mouring at eviladmin.org
Thu Jun 20 01:02:48 EST 2013
On Jun 19, 2013, at 9:26 AM, Michael W. Lucas <mwlucas at michaelwlucas.com> wrote:
> 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...
Sounds like something that would be nicely paired with puppet, chef, or cfengine. So
it is managed.
Mind you this is what I would called an old school NIS solution. =) (remember back
when a "ypmake" actually rcp files to client machines from the master? =)
It comes with all annoying sync issues of the old school NIS solution as well as other
issues (bad rhost files, badly maintained client lists, machine down during the push, etc).
It may be better from a security point of view to centralize that SQLite database, and use
an existing protocols like https:// to talk to a CGI server to acquire the information. Then lock
it down via IP or secret tokens or whatnot. It removes the "my machine was down" issue
which could leave it out of sync (at worse leave keys around that you thought were gone).
- Ben
More information about the openssh-unix-dev
mailing list