[Bug 1663] Allow to use agent for distribution of public keys.

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Mon Mar 1 19:49:20 EST 2010


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

jchadima at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jchadima at redhat.com

--- Comment #4 from jchadima at redhat.com 2010-03-01 19:49:19 EST ---
(In reply to comment #3)
> This is an interesting idea. My concerns are:
> 
this is not necessary limited to LPK compatibility, even the transport
protocol, may be different.


> 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.
> 
the keys are transported as is with all the prefixes (forced commands
&tc..)


> 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.
> 
a) The per session fork may be useful, when the executed process should
be run under the authorized user privileges.

b) 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.

> 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.
> 
> We should probably discuss this on the mailing list.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list