Bug 105710 - sshd not accepting connections
Summary: sshd not accepting connections
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-26 19:10 UTC by Ted Kaczmarek
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-05 16:39:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Debug of sshd hosing (1.94 KB, text/plain)
2003-09-29 20:01 UTC, Ted Kaczmarek
no flags Details

Description Ted Kaczmarek 2003-09-26 19:10:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030701 Galeon/1.3.7

Description of problem:
Clients get ssh_exchange_identification error, restrting daemon will fix for
about 30 minutes. Will also start working by itself after some undetermined
period of time.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.up2date openssh
2.ssh to up2date sshd

Actual Results:  ssh_exchange_identification: Connection closed by remote host

Expected Results:  ssh connection establishes

Additional info:

I am able to reproduce this at will.

Comment 1 Ted Kaczmarek 2003-09-26 21:01:07 UTC
Reviewing my monitoring logs shows that is goes down between every 30-40 minutes
for between 30-60 minutes,

Comment 2 Ted Kaczmarek 2003-09-29 19:20:24 UTC
OK, every ssh daemon running 3.5X is affected, not all the same way. Any sshd
daemon that is 3.4X is not experiencing this issue. I have some running on port
2022 in debug mode, but I suspect these will not have an issue.

Comment 3 Ted Kaczmarek 2003-09-29 20:01:16 UTC
Created attachment 94833 [details]
Debug of sshd hosing

Why would not receiving an identification string cause the daemon to hose?
One would suspect it would just reject the connection. Anyway I have a few
workaround options but am amazed that this was let loose. Talk about a simple
way to DOS someone. 

Comment 4 Ted Kaczmarek 2003-10-26 21:35:42 UTC
it seems that opennms launches on ssh poller invocation abackground-task.If so ,
the check if I/O-channels STDIN,STDOUT and STDERR are linked toa local
file/device.e.g. ssh ares4 '/opt/opennms/doit_as_backgroundtask.sh
</dev/null+>/var/log/doit_as_backgroundtask.log 2>&1'If one of these I/O
channels are bound to the console then the sshd will not terminate correctly.
That's the reason I reach the redhat defaultlimit of maximum 10 sshd processes.
raising this limit to <30 helps. Forthe archive.

Comment 5 Alex Pircher 2004-01-12 09:24:04 UTC
I'm also unable to connect to one server using
openssh-server-3.5p1-11. This
has now happened for the second time within one month. Only a restart
of the
daemon fixes this:

# ssh -vvv web3
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
debug1: ssh_connect: needpriv 0
debug1: Connecting to web3 [] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x80674e0(0x0)

Comment 6 Ted Kaczmarek 2004-01-12 11:55:24 UTC
How may sshd's do you see running when this happens?
You will need console access or enable another  daemon that you can
remotely access host with. You may want to increase the amount of
sshd's allowed to 30, that so far has prevented my problem, it will
get up to about 24-26 typically in my setup. 

Comment 7 Tomas Mraz 2005-02-04 16:35:48 UTC
Does it still happen for you with the current Fedora Core?

Comment 8 Ted Kaczmarek 2005-02-04 23:34:55 UTC
Wouldn't be able to tell you for sure, the OpenNMS guys accidentally
created the DOS that did this with one version of their ssh poller. I
haven't seen any problems with this since I upgraded the poller code. 
That was quite some time ago. 
I would say close it at this time.

Comment 9 Tomas Mraz 2005-02-05 16:39:41 UTC
It's possible that it could be a problem of syslog deadlock which was
reported in another bug report. Closing for now.

Comment 10 Mark Huang 2005-05-04 14:59:43 UTC
I believe that the root cause of both this bug as well as <a
href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144799">144799</a> is
a bug in OpenSSH 3.6.x and 3.7.x that only shows up under privilege separation:


Basically, the MaxStartups (10) and LoginGraceTime (120 seconds) settings are
supposed to defend against DoS, but when run in privilege-separated mode (the
default), OpenSSH server does not properly kill its children after
LoginGraceTime expires. Thus, sshd processes that are still in authentication
phase after LoginGraceTime expires can hang around forever, and you can DoS an
FC2 OpenSSH server with default settings by simply opening up 10 connections to
the server, specifying an SSH key with a passphrase, and never typing the

We recently upgraded all 500 of our <a
href="http://www.planet-lab.org/">PlanetLab</a> nodes, which run a modified FC2,
to the latest FC3 version of OpenSSH server (3.9ish), which seems to have fixed
the problem. The latest FC3 version of OpenSSH server does have some annoying
New Requirements ("locked" accounts (those with "!!" passwords in /etc/shadow)
must be "unlocked" ("!!" replaced with "*"), the server refuses to start unless
argv[0] is an absolute path (i.e. you cannot rename the process)), but works.

Note You need to log in before you can comment on or make changes to this bug.