Bug 2576

>  Lennart Poettering 2016-05-04 18:28:09 CEST

ssh-agent starts eating 100% if it gets bombarded by connections, and runs out of file descriptors to use. Looking at strace, it starts to cycle in a select() loop, where the listening AF_UNIX socket is reported active, which makes ssh-agent invoke accept() which will then fail with EMFILE. It will then immediately invoke select() again, and be in a busy loop from then on.

I figure ssh-agent should enforce a limit on concurrent connections (that is much lower than RLIMIT_NOFILE) and quickly terminate further incoming connections when that limit is hit. Most internet software handles this that way, and I figure ssh-agent should do that too for incoming local clients.

I noticed that while creating a ton of ssh connections to my local system in a tight loop, which uses the ssh keyring.

(When ssh-agent is in this mode, and you start further ssh instances with the & suffix in a shell (to make it background), then they will also enter a busy loop handling of SIGTTOU. I don't have further details about this, though, was too lazy to figure out what is really going on there).

>  Jakub Jelen 2016-05-26 17:01:26 CEST 

I was trying to burn my virtual box with a lot of requests to ssh-agent but only with partial success. But the behavior you explain sounds possible.

My test case:

  eval `ulimit -n 10; ssh-agent`
  ssh-add rsa
  cat rsa.pub >> .ssh/authorized_keys
  for i in `seq 1 128`; do ssh localhost id & done
  ls /proc/$SSH_AGENT_PID/fd/ | wc -w

and I am left with few cycling ssh processes in some cases, or with the ssh-agent live-locked.

-----------------------------------------------------------------------------

Copy from RHBZ#1333105 [1]. I can hack this somehow, but upstream fix with proper evaluation would make more sense, if it is considered as an issue.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1333105