Allow to use agent for distribution of public keys

[Jan Chadima]

Discussion to the https://bugzilla.mindrot.org/show_bug.cgi?id=1663

> 1) you lose the ability to specify key restrictions. I.e. you can't
> force commands on a per-key basis, disable port-forwarding, etc.

This extension is designed to provide some non kerberos possibility
to create domains for groups of roughly equivalent users. It distributes
the authorized keys from a single point in the form of the file "authorized_keys"
with all the functionality. It is possible to make more "match" sections 
in the sshd_config with the same or different agent specifications and with
the different other options. 

> 2) I think it would be better if you don't run the agent from sshd.
> Instead, you add a single directive to sshd_config to inform it of an
> agent socket path and use ssh-agent's "-a" option to make it listen on
>a single location.

The per session fork may be useful, when the executed process should be run under the
authorized user privileges.  

> 3) ssh-agent has not be written with robustness against deliberately
> malformed input in mind and will fatal() at the first encoding error.
> This is good behaviour for a per-user agent, but could lead to
> system-level DoS when used to manage public keys for a host.

The fork-execute at each autentization have some advantages and some disadvantages.
The advantages are: better stability - killing the process does not cause the DoS.
Less vulnerability for memory leaks. The process finishes with all non freed memory
after each authentization.
The disadvantages: more process and more sockets used.

The brute force atack may cause the DoS, but I'm not sure which resource will be short first.
In the case LDAP transfer it will be surely the LDAP server :)

-- 
JFCh