SCP is slow in 1 out of 3 directions!!! different than most things

[marvin51796]

>if logged into khupepc001 and issues a scp /tmp/aectst khepx019:/tmp/aectst it takes 5 seconds

>To be complete, can you reverse this and get the 4th direction and time?

Sorry missed this before, being logged into khepx019 and doing scp /tmp/aectst khupepc001:/tmp/aectst takes about 4 seconds.

[Bill Hassell]

Have you tried ftp in the slow direction? ftp has the lowest overhead and will generally send larger packet sizes than scp.

[marvin51796]

yes we have tried FTP and secure FTP  and we have slowness, cisco is saying we either have to slow down stuff, or upgrade stuff .....they cant talk to each other using the new speeds.

[marvin51796]

can anyone tell me what this means? i dont know how they are getting this or what it means

protocol : SSH-1.99-openSSH_5.8p1+

i am trying to figure out how to check this on ever hp-ux machine but i dont know what to look for

This is from an scp and they are saying the two machines dont have the same software..cuz one is 1.99 and the other is 2.00

I can see the SSH version when i do a swlist -l product | grep -i Secure, but i dont know what to look for to see the SSH 1.99

[Matti_Kurkela]

> protocol : SSH-1.99-openSSH_5.8p1+

When a SSH connection is initiated, one of the first things that happens is that the server side announces its SSH protocol version level, since there are two main versions of the SSH protocol standard. The protocol version "1.99" means this server will accept both protocol versions: a client supporting the protocol version 1.x only will see that the major version is still "1.x" and will proceed with the connection attempt instead of stopping with an "incompatible SSH protocol versions" error message.

All the SSH clients supporting protocol version 2 will know that server-side protocol version "1.99" means the server actually supports protocol 2, but is willing to downgrade to the older protocol version if necessary.

The "openSSH_5.8p1+" part is the software version. It is announced so that if the client is newer than the server and knows about bugs in that particular server version, it can automatically apply any required workarounds.

As the SSH protocol version 1.x is known to have some weaknesses at its fundamental design, you should not be using it unless you have clients that only support protocol version 1.x and cannot be upgraded. Check the "Protocol" statements in your sshd_config file (typically /opt/ssh/etc/sshd_config in HP-UX): if it says "Protocol 2,1" it means the server supports both protocol versions but will prefer version 2 if the client can also use both versions. 

Change it to "Protocol 2", restart sshd, and then the "1.99" will be gone. Then the protocol will be identified as 2.00 instead, as the support for the obsolete protocol version 1.x will be disabled.

[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.