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
