openssh bugs - Nov 2011 - [Bug 1213] ssh-keyscan exits in mid-way

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #37 from Daniel Richard G. <skunk at iSKUNK.ORG> 2011-11-25
12:40:45 EST ---
Yet another failure mode...

[...]
# XXX.YYY.ZZ.8 SSH-2.0-Sun_SSH_1.1.3
# XXX.YYY.ZZ.9 SSH-2.0-OpenSSH_3.8.1p1
# XXX.YYY.ZZ.14 SSH-2.0-OpenSSH_4.3
# 10.10.1.35 SSH-2.0-RomSShell_4.62
Received disconnect from 10.10.1.35: 2: Protocol Timeout
make: *** [ssh_known_hosts.unx.new] Error 255

This is with 5.8p1 still. aab@, I'll have to give your latest patch a
try.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #38 from aab at purdue.edu 2011-11-25 18:19:27 EST ---
I haven't seen this one before.  The text you included indicates that
ssh-keyscan was processing a Protocol 2 key and it should be using the
modified code to do it.  Is there any way that you could send me a
traceback when the failure occurs?

FWIW - I think the " 2: Protocol Timeout" part of the message comes
from the remote "SSH-2.0-RomSShell_4.62" server because I couldn't
find
that text in the OpenSSH source.  What is "RomSShell"?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #39 from Daniel Richard G. <skunk at iSKUNK.ORG> 2011-11-26
15:10:29 EST ---
(In reply to comment #38)
> I haven't seen this one before.  The text you included indicates that
> ssh-keyscan was processing a Protocol 2 key and it should be using the
> modified code to do it.  Is there any way that you could send me a
> traceback when the failure occurs?
I'll do that, when I'm back in the office. I'll use your patch.
(This
was with the stock Ubuntu build; it was just a failure mode that hadn't
been noted here before.)
> FWIW - I think the " 2: Protocol Timeout" part of the message
comes
> from the remote "SSH-2.0-RomSShell_4.62" server because I
couldn't find
> that text in the OpenSSH source.  What is "RomSShell"?
It seems to be an OEM embedded implementation of SSH... this was
probably a router or something.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #40 from Daniel Richard G. <skunk at iSKUNK.ORG> 2011-11-30
14:18:53 EST ---
Okay, I tried Ubuntu's packaging of OpenSSH (version 1:5.8p1-7ubuntu1)
with your patch, and it powered through everything. Here is a list of
all the error messages I received:

A.B.C.D: Connection closed by remote host
Connection closed by A.B.C.D
Connection to A.B.C.D timed out while waiting to read
Received disconnect from A.B.C.D: 10:  Protocol error
Received disconnect from A.B.C.D: 10:  Protocol error
Received disconnect from A.B.C.D: 11:  SSH Disabled
Received disconnect from A.B.C.D: 2: Client Disconnect
Received disconnect from A.B.C.D: 2: Protocol Timeout
connect (`A.B.C.D'): Network is unreachable
no 'ssh-rsa' hostkey alg(s) for A.B.C.D
read (A.B.C.D): Connection reset by peer
read (A.B.C.D): No route to host

(This is ssh-keyscan output with /^#.*$/ filtered out, all IPs zapped,
and 'sort -u'd)

Now the question is, why hasn't this been checked in already! (Have you
tried making some noise on the mailing list?)

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #41 from aab at purdue.edu 2011-11-30 16:51:43 EST ---
(In reply to comment #40)
> Okay, I tried Ubuntu's packaging of OpenSSH (version 1:5.8p1-7ubuntu1)
> with your patch, and it powered through everything. Here is a list of
> all the error messages I received:
> 
> A.B.C.D: Connection closed by remote host
> Connection closed by A.B.C.D
> Connection to A.B.C.D timed out while waiting to read
> Received disconnect from A.B.C.D: 10:  Protocol error
> Received disconnect from A.B.C.D: 10:  Protocol error
> Received disconnect from A.B.C.D: 11:  SSH Disabled
> Received disconnect from A.B.C.D: 2: Client Disconnect
> Received disconnect from A.B.C.D: 2: Protocol Timeout
> connect (`A.B.C.D'): Network is unreachable
> no 'ssh-rsa' hostkey alg(s) for A.B.C.D
> read (A.B.C.D): Connection reset by peer
> read (A.B.C.D): No route to host
> 
> (This is ssh-keyscan output with /^#.*$/ filtered out, all IPs zapped,
> and 'sort -u'd)
The number of ways that key access can be terminated keeps increasing,
doesn't it?

FWIW - the message "A.B.C.D: Connection closed by remote host" has
been
changed to "read(A.B.C.D): Connection closed by remote host" to be
more
consistent with the other messages (as above) issued in the same code
block.
> Now the question is, why hasn't this been checked in already! (Have you
> tried making some noise on the mailing list?)
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.

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?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1213

--- Comment #42 from Daniel Richard G. <skunk at iSKUNK.ORG> 2011-11-30
17:12:55 EST ---
(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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.