On Fri, Mar 21, 2014 at 8:39 PM, Stephen Harris <lists@xxxxxxxxxx> wrote:
> I'm jumping in here, just because it's the last message in the thread
> that I've received so far.
>
> I'm not sure if this patch is solving a problem that really exists.
>
> What's wrong with
> command="/path/to/command user1" ssh-dss key1...
> command="/path/to/command user2" ssh-dss key2...
> command="/path/to/command user3" ssh-dss key3...
> I've been doing that for years.
The problem is more a problem of performance and scalability rather than
functionality. Specifying the command in the keys, as you demonstrated, is
still required to identify the user that owns the key. This is regardless
of whether it comes from AuthorizedKeysCommand or AuthorizedKeysFile.
But that's just a flat file stream, and sshd has to scan through every one
to find the first match. When you're dealing with thousands or millions of
keys (I'm not doing this, but places like GitHub are), that linear search
becomes an issue. Being able to know what key is coming in enables one to
perform a database lookup, which can be indexed, and is therefore much
faster and much more scalable.
> If there is a problem then here's two alternatives...
>
> If we _do_ want to allow the key to be passed, why not pass the signature
> rather than the key?
Passing only the fingerprint was something we discussed earlier in the
thread. It would still work for some use cases, but instead of returning
only the exact match(es) to sshd it would return those that match the
fingerprint (which might have collisions). In this case sshd would still
be dealing with a small subset of all keys and would find the first key
that does exactly match.
> If we actually want the real key then do something similar to agent
> forwarding; put the used key into a (secure) temporary file and pass the
> filename in an environment variable. After the child process has exited
> then clean up the temporary file. Just like agent forwarding. In this
> case control it by another config file setting ("PassSSHkeyToSession yes")
> so we don't write files for no good reason.
That seems to be overkill for public keys.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
