SSHD dispatch protocol errors

[Luis Toro]

We have ssh (A.04.10.004) running on an HPUX 11.0 server. Users are complaining about slow response time, and we see alot of "dispatch_protocol_errors" (type 16 and 19) in the syslog. I'm not sure if that could be the source of the problem, since it seems that we've been getting these errors since we went to ssh a while ago. What do these errors mean ? Did a "google" on the errors and there was a reference to RekeyIntervalSeconds (in sshd_config), but that does not seem to be an option per the sshd_config man page.

Thanks

[Sandman!]

What version of ssh are the clients and server running?

[Luis Toro]

The HPUX server is running 11.0 of the OS, and we just installed the latest version of SSH. The "swlist" command shows version A.04.10.004. In the README, it references OpenSSH 4.1p1. The clients are citrix-based, and the ssh software is E-Term32-Vt320, by a company DCSI, version 3.00.165

[Denver Osborn]

I think the "RekeyIntervalSeconds 0" would be a setting on your client side, not with the hp-ux's OpenSSH config.

-denver

[Denver Osborn]

On one of the problem clients, what does "ssh -V" return?

-denver

[Steven E. Protter]

Your version of ssh is current.

I would look into a misconfiguration problem with ssh_config or sshd_config or a networking issue.

Perhaps try config files from a server that does not have this problem.

ssh connect problems for me have been a precursor to network card failure, though not with this particular error.

SEP

[Luis Toro]

Is there a way to figure out on the server side which connections (ie., from what IP address) are yielding these messages ? A little more background: the users complaining about response time are in remote offices, using the citrix "thin-client" to access, among other things, this terminal-based app on the HPUX server. The feedback I get is that users in the main office (non-citrix) are OK. Although other possible issues are being investigated, I need to make sure these errors are not the cause. Could they be an effect of a network bottleneck ?
Thanks

[Zeev Schultz]

Hovewer,RekeyIntervalSeconds=0 is for "dispatch protocol errors type 20".Which is happily resolved since OpenSSH 2.4 (I think) :

http://www.openssh.com/faq.html#2.4
http://www.snailbook.com/faq/no-rekeying.auto.html

I would check with another SSH client.Take for example putty,see if your users have the same issues.

[Denver Osborn]

It may help to know what ssh versions your clients are using... "ssh -V" on the clients will show the rev of ssh being used. Compare working revs to non working revs and go from there... If there are some clients who are able to connect to the sshd listner on the hp-ux box, I'd focus on the remote clients 1st as the server config may not be the problem. What do the problem ssh clients have in common (ssh rev, protocol)? What do the "working" ssh clients have in common?

hope this helps,
-denver

[Luis Toro]

Denver,
the 'ssh -V' command is not a valid command. These are Windows clients running a terminal emulation software, with an ssh extension. Unfortunately, this is the only environment that has replaced telnet with ssh (ie., we're not running ssh anywhere else). I don't think it is a server issue either, but since we have these messages on the server side, I have to do the research. Doing a "grep" on dispatch_protocol_error" yielded 2000 messages in a weeks time period. Seems users can connect; just response time is very slow. My guess is this probably has nothing to do with SSH, but I'm looking for an explanation of these specific error messages (seems I was barking up the wrong tree with the rekeying).
Thanks again

[Denver Osborn]

Is this the product being used? They don't have much documented about the ssh support... might be worth a shot to involve their tech support for tips.

http://www.minisoft.com/pages/connectivity/secure320/secure320.html

-denver

[Luis Toro]

The product is eterm:
http://www.dcsi.com/terminalemulation/eterm32.asp

I've opened up a call with HP to see if they can provide details on the specific error messages. I have to go through an Applications group for support (or lack thereof) of this product, so before I lob the ball back on their court, I want to make sure I've exhausted all avenues on the HP side.
Thanks

[Charles Kangas]

Is there an update to this?
I am seeeing the same issues.

Thanks

[Luis Toro]

Here's a summary of what I received from an HP engineer upon opening a software call with HP Support:
The messages are normally harmless. They are a result of HP's ssh not being able to interpret what the client ssh [in my case, Eterm's ssh] is sending. HP recommended we contact Eterm support to find out if they had developed some features in their ssh product that Openssh does not have. As such, I "passed the buck" to our desktop software support, and have not heard anything since. This was an issue for us since we were having intermittent performance issues on an HP9000 server, and we had to investigate any anomolies. The performance problem has since been resolved, and we're still getting these messages, so we closed the matter. Hope that helps.

[Charles Kangas]

Thanks!

I guess my next call will be to DCSI as we too are using E-term32.