openssh unix dev - Apr 2013 - AuthorizedKeysCommand question

Hi,

is there a particular reason why this feature is "user" based and not
"user-pubkey" based?

What I mean is that it works for installation with small number of pubkeys
per user.
But imagine i.e. a GitHub scale - all users logging in as user "git".
On
each auth request all the keys from database would be fetched and feeded to
OpenSSH.

Now I am only asking this out of curiosity - was it easier to implement it
the way it currently is?

Currently it executes one external command per auth request.
If we would like a larger scale support, we would need to make it
configurable to support one external command execution per presented pubkey
(user may present multiple pubkeys, of course). Something like:
AuthorizedKeysCommand "/path/to/auth %u %p"
# %p is made up, but it stands for pubkey fingerprint

b.

On 04/04/2013 11:52 AM, Bostjan Skufca wrote:
> is there a particular reason why this feature is "user" based and
not
> "user-pubkey" based?
i think this question has been discussed on this list before.  you might
get better details from searching the archive.

> Now I am only asking this out of curiosity - was it easier to implement it
> the way it currently is?
the  implementation was definitely simpler this way because it can reuse
all the existing code that parses authorized_keys files, substituting a
pipe from a process instead of a text file as input.
> Currently it executes one external command per auth request.
> If we would like a larger scale support, we would need to make it
> configurable to support one external command execution per presented pubkey
> (user may present multiple pubkeys, of course). Something like:
> AuthorizedKeysCommand "/path/to/auth %u %p"
> # %p is made up, but it stands for pubkey fingerprint
I can see the appeal of having this sort of functionality, but i do not
think openssh should be in the business of string mangling in this part
of the configuration.

If you're going to match user-pubkey, i would recommend that the
convention is that the user account is the first argument, and the
pubkey is provided to the authcommand on stdin in some canonicalized form.

We'd want to be backward-compatible with the existing implementation as
well, so it'd be worth thinking about how to clarify which model sshd
should use.  One approach would be a configuration variable like
AuthorizedKeysCommandMethod, which can take two options: listkeys
(current implmentation, default) or testkey (your proposal).

iirc, there are some significant changes to flow of control and
authorization logic needed to implement the testkey method.  I'd be
happy to review patches that offer this functionality and give feedback
on them.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130404/7d691193/attachment.bin>

On Thu, 4 Apr 2013, Bostjan Skufca wrote:
> Hi,
> 
> is there a particular reason why this feature is "user" based and
not
> "user-pubkey" based?
> 
> What I mean is that it works for installation with small number of pubkeys
> per user.
> But imagine i.e. a GitHub scale - all users logging in as user
"git". On
> each auth request all the keys from database would be fetched and feeded to
> OpenSSH.
There's a bug for this:

https://bugzilla.mindrot.org/show_bug.cgi?id=2081

We're considering exposing the public key to the command, perhaps in an
environment variable.

-d