SSH issue... more likely a symptom

[sbrews]

I have a system (11.11) with ssh V 3.6.1p2 installed on it.  I have another server (also 11.11) with ssh V 5.9p1 installed.

I can connect to the V5.9 system from my laptop without issue.  I can connect to the V5.9 system from some of my newer boxe (11.31) without issue.  I cannot connect to the V3.6.1p2 box from the V5.9p1 box nor vice-versa.  An ssh attempt (in either direction) will eventually result in "did not receive identification string from..." error message.

I have checked out my ssh_config and sshd_config files - all look ok.  I have googled... and while I found lots of people encountering the same error, I havent been able to find a solution to this.  Is this just due to the age of the older ssh?  Is there a way to fix - without updating the older ssh (not an option at this time)?

scott

[sbrews]

To expand on this - and hope someone might see what I am missing.

Server A is 192.168.28.70

Server B is 10.50.16.28

Server C is 10.50.16.30

I can successfully traceroute/ping/ssh/etc between servers A/B, B/C. 

Traceroute from server C to A works, but not A to C.  SSH between A/C does not work.  Ping, Telnet, FTP between A/C does work.  My network person tells me there is nothing on the network side to cause this (ie, no firewalls).

Is there anything within HPUX 11.11 - ie host based firewall (been away from hpux for awhile, but I dont recall it having host based firewalls like iptables in linux) -  that would account for this?

[sbrews]

Ok, at wits end - telnet, ftp, etc. work to my host from some servers and not others.  Is there anything within HPUX networking that would possibly account for this strangeness?

IP addresses, netmask and gateway settings have all been verified.

[Matti_Kurkela]

There is an optional IPFilter package which can be used to create filtering rules similar to iptables on Linux, although the configuration syntax is very different.

See if the /etc/opt/ipf directory exists: that's the place where the IPFilter configuration should be if it is installed. Run "ipf -v" as root to identify IPFilter version, and "ipfstat -io" to see the current input/output rules.

Documentation can be found at http://www.hp.com/go/hpux-security-docs -> HP-UX IPFilter Software.

This FAQ document of the open-source ipfilter project (which the HP-UX IPFilter is a port of) might be helpful too:

http://www.phildev.net/ipf/index.html

[sbrews]

Still havent found the cause of the problem, but some more info in case someone can see the problem that I am missing...

The optional ipfilter software is not installed.

The server is in the 10.50.* range.  Any other server in the 10.50.* range can successfully communicate with this server (ftp, telnet, ssh, etc).  Anything outside of this range (for this 1 server only) cannot successfully communicate.  Via tcpdump, I do see that initial communication attempts reach the server, but it goes non-responsive after that.  I can also observe that directly with telnet - I get a login prompt and then no further responses.

The netmask and gateway have been checked/verified several times over and they are displaying the correct values. 

[Matti_Kurkela]

The sshd daemon might log something useful about the connection attempts to the syslog (/var/adm/syslog/syslog.log in HP-UX). What does it say?

Where did you run that tcpdump? On the server, on the SSH client or somewhere in-between?

To get to the bottom of this mystery, you might need to run two tcpdumps simultaneously: one at the server and another at the client, while you make a connection attempt. Comparing the two dumps might bring enlightenment. Running traceroutes both from the client towards the server and vice versa might be useful too.

Is a gateway required to communicate between the hosts within the 10.50.* range and the hosts outside it? Are any firewalls (or any other devices capable of stateful packet inspection) involved?

This might be a routing issue: for example, if the first response packet from the server gets duplicated and the duplicate enters a routing loop, it will take a while (in computer timescales, i.e. maybe tens or hundreds of milliseconds) to exhaust its TTL going around and around in the loop - perhaps just enough for the TCP three-way handshake to complete (and the telnet login prompt to display).

But as soon as the first of the packets caught in the loop exhausts its TTL, the router that sees it happen will send an ICMP error packet back to the sender (i.e. the SSH server). As the ICMP packet reaches the server, it will assume the connection has failed and will abort the connection. From the viewpoint of the client, the server just stops responding for no apparent reason. From the viewpoint of the server, the connection was aborted because of a network error.

[sbrews]

After much gnashing of teeth and lots of testing, etc. it was found that there was an old bug related to iether where packets would be padded to a minimum required length.  This padding, apparently, cannot be handled by our older systems... the newer systems had no issue and is why they worked where the others didnt.

Long story short, a patch was found that addresses the bug.  Once installed, the communications problem went away.  For anyone who is interested, the patch is PHNE_36237.