splitting big authorized_keys files

[mike808]

> On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote:
>>  lrwxrwxrwx ... sarah -> Authkeys_P_to_T
>>  lrwxrwxrwx ... thomas -> Authkeys_P_to_T
>
> you want to have sarah login as thomas?

No. That won't happen.

Authkeys_P_to_T (in the example) will contain _all_ of the authorized
keys for all user names beginning with the letter "P" through the
letter "T".

That means that both Sarah's key and Thomas' key will both be
found in this file. The idea is that it will be faster (supposedly,
and unproven) to find the supplied key in a smaller file (with fewer keys)
than in a larger file (with more keys).

Think of it as a hash function with only five buckets, in this example.
The trickery with the symlinks is what "implements" the hash function
on the user's name to determine which bag of authkeys to look in.

This technique is about as old as dirt, and is used in other areas,
like client-based automatic proxy server load-balancing. That works
by taking a hash of the URL that is then used to pick which proxy server
to use.

Presto, all clients asking for a specific URL are always routed to
the same proxy server, which makes each proxy server's cache very, very
efficient. The function of "picking" the proxy server to use is where
you can add in arbitrary logic and weightings.

In the SSH case, the function of "picking" which authorized_keys file
to use is limited to a single file, a per-host file, or a per-user file.
In the OP's request, a per-host file is the same case as the single file,
so the per-user file choice is the only real option (without changing
SSH to add new "picking" functions (i.e. new tokens in AuthorizedKeysFile).
The symlinks just provide the "load-balancing" or "hash" function and
instead of operating on a URL, operate on the user name.

I hope that explains how my suggestion works.

Mike/