SCP is slow in 1 out of 4 directions! Different than most things

[Dennis Handly]

>I can see the SSH version when i do a swlist -l product | grep -i Secure

This gives the HP-UX version.  If you want the ssh version use: ssh -V

[marvin51796]

Matti

both the client and server say Protocol 2,1. Is there a reason it is using 1.99 stuf??? i  guess i dont understand if both systems are setup for 2 why is it not being used on both ends?
thanks

[Matti_Kurkela]

> both the client and server say Protocol 2,1. Is there a reason it is using 1.99 stuf???

According to the SSH protocol specification (both protocol versions), when a SSH connection is established, the server must declare its protocol version to initiate the connection set-up, without knowing anything at all about the capabilities of the client.

According to the original SSH 1.x protocol spec, an increase in a major version number means a backwards-incompatible change in the protocol, so if an old client that only supports protocol 1.x receives a protocol version string with "2.0" in it from the server, the client will get a terminal case of shyness, display an error message "incompatible protocol versions" to the user, and abort the connection. So, the server *must* declare a 1.x version number if it is going to allow old protocol 1.x clients to connect. 

The protocol version number "1.99" is a kind of "secret handshake" that is still SSH 1.x compliant, but offers a clue that protocol version greater than 1.x is supported too. If the client also claims a 1.x protocol version, then the connection will proceed using SSH 1.x protocol; but if the client also indicates that it supports higher protocol versions, then protocol version 2.0 will be used.

Apparently "they" who produced the protocol identification string did not do any deep analysis of the SSH server capabilities, just captured the initial protocol version string sent by the server and presented it as-is as the protocol identification. You can do the same by simply telnetting to the SSH port of any server that has sshd running: the server will send its version string as human-readable text, wait a while, and then cut the connection since a telnet client cannot complete a SSH session key exchange.)

[marvin51796]

Thanks for the great explanation of this, its helpful, now if we can just get the cisco hardware to work with the hp hardware..LOL..
thanks again to everyone , you all have been so helpful

[marvin51796]

Just to add more information to anyone who might run into this, apparently the issue is that we were going from a 10G HP switch in a blade chassis, to a 1G Cisco switch in another blade chassis. The issue was resolved by useing the second sets of ques in each switch. We are using the ques that are setup for Telephone and other traffic as the primary for our ECP traffic. apparently this happens to IBM and DELL chassis also.