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