[patch] Threading support in ssh-agent

[Jamie Beverly]

----- Original Message -----

> From: Nico Kadel-Garcia <nkadel at gmail.com>
> To: Ángel González <keisial at gmail.com>
> Cc: Alexander V Alekseev <alex at alemate.ru>; openssh-unix-dev at mindrot.org
> Sent: Sunday, March 11, 2012 3:14 PM
> Subject: Re: [patch] Threading support in ssh-agent
> 
> 2012/3/11 Ángel González <keisial at gmail.com>
> 
>>  On 11/03/12 19:57, Alexander V Alekseev wrote:
>>  >         Hi all!
>>  >
>>  >     I do not know openssh patch policy so I am just sending
>>  > the patch to the mailing list. Sorry for inconvenience.
>>  >     Ssh-agent seems to be too slow if you need to access thousands of
>>  > servers. This is a simple patch to enable threading in ssh2
>>  > authentication.
>>  > Patch adds "-p numthreads" option and defaults to the number 
> of
>>  > processors.
>>  >
>>  >     I've tested it as I could, but unfortunately I could check it
>>  > only in Linux environment. Though it shouldn't break anything.
>>  >
>>  >         Bye. Alex.
>> 
>>  You concurrently access thousands of servers? O_O What's your use case?
>>  How does your threaded ssh-agent work with keys requiring confirmation?
>>  Would the user be flooded with a SSH_ASKPASS instance per thread?
>> 
>> 
> I can think of several. Scripting of network wide surveys, rsnapshot over
> large environments, and Nagios over   ssh plugins leap to mind.

I haven't looked over the patch, but I can confirm the real-world use-case for using ssh-agent for authentication on thousands of hosts concurrently. 
I regularly ssh to several thousand hosts (several times a day on most days) for various reasons. Many uses are just to execute a single command on thousands of hosts in parallel and aggregate the output, other uses are as above. Up until now, I've just had my scripts automatically partition the work between multiple agents, usually with about 100-300 concurrent jobs per agent. Of course this means entering the password for the keys for multiple agents, which is an annoyance at after reboots.

I would wager this is a similar for others in the LSPE space.

So, while I can't speak to the patch, I can at least confirm the existance of the usecase.