patch to send incoming key to AuthorizedKeysCommand via stdin

[Eldon Koyle]

On  Mar 24 17:23+0100, Peter Stuge wrote:
> Scott Duckworth wrote:
<snip>
> > but once the pipe's buffer fills up and it is not emptied then
> 
> ..it will no longer be writable. Does the last write() before buffers
> are full return short? If not, only write() a single byte at a time.
> 
> I still do not see the problem here.

The default behavior is for the last write() to block until the buffer
empties.  You could possibly open the pipe with O_NONBLOCK (not sure how
universal the support for this is), however I think the environment
variable is the more friendly way to handle this.

Writing to stdin, do you just give up if it would block?  What if the
process was just busy and still needs to read the key?  Add some kind of
timeout?


> > timeout
> 
> A timeout within any general purpose OS is a heuristic, I don't think
> they belong in the authentication path.

Does sshd fork before it handles a client authentication request?  If
so, the blocking is more or less a non-issue, as it will not block
other authentication attempts.  If the AuthorizedKeysCommand runs
normally, it will exit and close the pipe.  This only becomes an issue
if the command hangs forever, which it would likely do with or without a
pipe.

What currently happens if an AuthorizedKeysCommand hangs?


> > there's likely already a lot of commands in use that do neither of these.
> 
> So maybe the new semantics deserve a new configuration option, rather
> than extending an existing option in a not-so-scalable way?

I think the environment variable is cleaner and easier than adding a new
configuration option or trying to handle a full pipe.  I suspect that
there aren't very many operating systems that currently run openssh that
would be affected here, and I also suspect that any OS with such tight
memory requirements would opt to run something more like dropbear than
openssh.


-- 
Eldon Koyle
-- 
BOFH excuse #355:
Boredom in the Kernel.