[Bug 483928]

[Daniel Richard G.]

(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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/483928

Title:
  ssh-keyscan(1) exits prematurely on some non-fatal errors

Status in Portable OpenSSH:
  Confirmed
Status in “openssh” package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: openssh-client

  This concerns openssh-client 1:5.1p1-5ubuntu1 in Karmic.

  I am using ssh-keyscan(1) for its intended purpose: building an
  ssh_known_hosts file for a large network. Most of the hosts on this
  network are well-maintained systems, with properly-functioning SSH
  servers, and present no difficulty to the program.

  However, a handful of hosts are barely alive, with SSH servers that
  are not exactly in good working order. ssh-keyscan(1) currently will
  scan these systems, encounter some form of error, and then---right
  here is the problem---exit in the middle of the scan. The last bit of
  stderr output may look like

  	# A.B.C.D SSH-2.0-OpenSSH_4.3
  	# A.B.C.E SSH-2.0-OpenSSH_4.3
  	# A.B.C.F SSH-1.99-OpenSSH_3.7p1
  	Connection closed by A.B.C.F

  or

  	# A.B.C.D SSH-2.0-OpenSSH_4.1
  	# A.B.C.E SSH-2.0-OpenSSH_4.1
  	# A.B.C.F SSH-2.0-mpSSH_0.1.0
  	Received disconnect from A.B.C.F: 10:  Protocol error

  or

  	# A.B.C.D SSH-2.0-OpenSSH_4.4p1
  	# A.B.C.E SSH-2.0-OpenSSH_5.0p1
  	# A.B.C.F SSH-2.0-mpSSH_0.1.0
  	Received disconnect from A.B.C.F: 11:  SSH Disabled

  (These are the different failure modes I've observed to date)

  ssh-keyscan(1) needs to be robust to these kinds of errors---simply
  make a note of them, and continue on with the scan. I don't want to
  have to find out which systems are misbehaving by running and re-
  running the scan (each run yields at most one bad host, obviously),
  nor manually edit out the few bad apples from the input list of hosts
  (especially considering that this particular subset can change over
  time). Neither is feasible when the number of hosts being scanned is
  very large.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/483928/+subscriptions