patch to send incoming key to AuthorizedKeysCommand via stdin

[Scott Duckworth]

On Sat, Mar 22, 2014 at 12:05 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:
> > You can check sysconf(_SC_ARG_MAX) to get an idea of the size limit.
> > See:
> >       http://www.in-ulm.de/~mascheck/various/argmax/
> > for more detailed information.
> >
> > Also, setenv/putenv should return an error rather than overflow the
> > buffer if the variable is too large.
>
> similarly, exec should fail with E2BIG if the data is too large.

I ran some tests and it looks like setenv does not return an error when
this happens but exec does (tested on Linux and Mac OS X).

> So this is testable at runtime, when the peer sends a large key; in the
> event that the variable is too large, AuthorizedKeysCommand would simply
> fail closed.  I think this is reasonable.

Agreed.

> We could also deliberately constrain the key size, and decline to
> execute AuthorizedKeysCommand (or execute it without passing any key as
> an environment variable or argument) if the client's proposed key is
> larger than the largest key generated by ssh-keygen (16Kib at the
> moment).  This strikes me as a reasonable limit.

If exec is catching the error for us then I don't see a need to impose
another constraint on it that will have to be maintained.

> Given the discussion, i'm still leaning toward either an environment
> variable or argv.  given that we're already using argv for the username,
> i think a second argv parameter would be the cleanest.

If compatibility with programs that expect exactly one command line
parameter (the username) then it seems like the environment variable is the
way to go.  But I'll leave that decision up to those more involved with the
development of openssh.