OpenSSH upgrade 4.1p to 5.1p brings ssh_exchange_identification trouble

Frank Burleigh fburleigh at gmail.com
Thu Mar 10 00:16:34 EST 2011


I hurt myself in an upgrade.  All was working well until a new requirement
made sshd.config's MATCH ADDRESS clause essential.  I'm hoping someone will
recognize how these facts correlate with changes made in the openssh
software.

Facts:

* SUSE Linux ES 10 SP2 x64
* Old openssh was 4.1p (from 2005)]
* New openssh is 5.1p, installed using SLES's software management tools
* No other software updated
* Firewall allows port 22 from the client
* hosts.allow had never been used -- it had no sshd rules

Behavior changes:

* Key exchange log in "ssh name at host" now fails (from OS X client) with
ssh_exchange_identification complaint, other servers ok

* On sshd 5.1p restart, server log shows
- sshd listening on :: on port 22 (old version always said this)
- sshd listening on 0.0.0.0 on port 22 (old version never said this)

* Connect attempts produce DEBUG3 log activity, text not available to me
right now -- I recall what looks like a process being forked.

Troubleshooting I've tried:

* Set logging to VERBOSE or DEBUG3 in sshd.config

* Disabled firewall

* sshd -t produces no complaints

* Check ps aux -- I see maybe one sshd process

* Enable PasswordAuthentication (try to eliminate the machine's host key as
an issue)

* Tried "sshd : ALL" and "sshd : ALL : ALLOW"  in hosts.allow.
- It's my impression hosts.allow changes take effect without needing a
restart of anything.
- hosts.deny has one active line, and says nothing about sshd.

The sshd log shows *some* activity on connect attempts but nothing about *my
account or key* -- looks like process and networking stuff.  I can't tell if
that activity is pre- or post-tcp_wrapper interrogation.  I'm trying to
learn *where* sshd gives up on my connect attempts.

I'm obviously dead in the water without a direction.  Any nudges toward a
better path would be appreciated.


More information about the openssh-unix-dev mailing list