Comment 44 for bug 483928

Revision history for this message
In , Daniel Richard G. (skunk) wrote :

(In reply to comment #41)
>
> The number of ways that key access can be terminated keeps increasing,
> doesn't it?

I hope it won't be necessary to enumerate them all before this bug can be closed!

> My oops. I have had my focus redirected to other projects and,
> besides, I'm very lazy (;-}).
>
> Dumb me, I thought at least a question or two would be forthcoming from
> the OpenSSH folks. Guess not. I saw the mailing list reference in the
> README and promptly forgot about it. I will send the patch there. I
> apologize for the slowness.

Hey, it's your patch. All the fame and glory will go to you ;-)

> Question for you. The ssh-keyscan code currently limits the maximum
> number of used file descriptors to <256. The biggest problem that I've
> seen with that number is, if you ever have a very large number of down
> hosts (which we have had), the code uses the available fds and has to
> wait for a '-Tn' timeout on one of them to start another key access.
> I've made a local modification that changes that number to 512. The
> code seems smart enough so that, if the OS has smaller limits, nothing
> will break. Right now Debian defaults to 1024 fds max and (at least
> our) Redhat to 20480. So 512 is a modest increase. Would you have an
> opinion on this?

Debian has 1024 fds max per process, or across the entire system? (If a local DoS attack were really as easy as calling open() ~1000 times...)

If the limit is for the whole system, that would be a good reason to make this an option, or a recognized environment variable. If for a single process, then just call sysconf(_SC_OPEN_MAX) and go to town.