Feature Request: Plugin Model for authorizing public keys
Mark Cavage
mark.cavage at joyent.com
Thu Feb 10 03:26:55 EST 2011
The purpose of this patch was to enable cases where there is not a
Kerberos deployment to manage keys centrally. So, I don't view this
and the kex patch as mutually exclusive.
I read through the bugzilla report regarding AuthorizedKeysCommand;
while my personal preference for this sort of mechanism is an
in-process plugin, I'm obviously not on the core team and have no real
concerns about that. I do think the semantics are not what I would
have expected though, as having the facility to effectively generate
an authorized_keys file on the fly is almost achievable with some
clever crons anyway. I would make the case that the functionality I
would want to see would be a process version of what I proposed
originally; that is given a key/user pair, a boolean value is returned
back to sshd. Also, I would want the existing authorized_keys file
checks to run first, not later, since with distributed deployments I
tend to think of per-host rules as overrides, as opposed to fallbacks.
I won't argue as strongly on the second point however.
What is the status/thoughts on the AuthorizedKeyCommand patch going
into mainline? If it's already blessed and going to get merged in I
can go ahead and create a patch off of that patch (assuming there is
agreement to my proposal above); the ticket is over a year old though
and being new to the list I don't know where that stands.
~Mark
On Wed, Feb 9, 2011 at 4:17 AM, Peter Stuge <peter at stuge.se> wrote:
> Simon Wilkinson wrote:
>>> At FOSDEM we had a short discussion about a similar simple way of
>>> also extending host key lookups, in lieu of the more intrusive GSSAPI
>>> kex patch which seems to take a different approach.
>>
>> The GSSAPI kex patch (an implementation of RFC4462) is designed to remove
>> the need for host keys entirely, rather than just making it easier to
>> verify that the key you've been given is valid.
>
> Right! We were briefly discussing why it might not yet have gotten
> included into OpenSSH.
>
>
>> On large sites - and some of the sites with GSSAPI key exchange
>> deployed have tens of thousands of machines - removing the need for
>> ssh host key management is a significant saving.
>
> Yes! Our thought was that maybe the same problem could be solved in a
> simpler fashion, not going quite all the way. Ie. still having host
> keys, but at least being able to validate them centrally using an
> already-acquired kerberos ticket.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
More information about the openssh-unix-dev
mailing list