Slow ssh on 11.11

[Danny Petterson - DK]

Hi Gurus!

Sorry guys, Ive already read and tried other suggested solutions on this forum, thats why I bother you with this:

I have a HP-UX 11.11-box running sshd, and its VERY slow before I get a loginprompt - slow from Unix-ssh and very, very slow from putty. Im pretty sure its not reverse lookup which causes the problem, and Ive also tried implementing /dev/random, which does not do the trick either. So Im a bit lost.

Under this message ive includded the debug-text from sshd - every time there is long pause in its doing, Ive typed in "##################", if thats any help.

Thanx alot for your time.

Yours
Danny Petterson

The output:
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 320
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 4, 4
debug1: audit connection from 10.45.255.77 port 21224 euid 0
Connection from 10.45.255.77 port 21224
debug1: HPN Disabled: 0, HPN Buffer Size: 65536
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
SSH: Server;Ltype: Version;Remote: 10.45.255.77-21224;Protocol: 2.0;Client: PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1+sftpfilecontrol-v1.2-hpn13v5
debug2: fd 4 setting O_NONBLOCK
debug2: Network child is on pid 1276
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 112:104
debug1: permanently_set_uid: 112/104
debug1: MYFLAG IS 1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-sha1
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: client->server aes256-ctr hmac-sha1 none
SSH: Server;Ltype: Kex;Remote: 10.45.255.77-21224;Enc: aes256-ctr;MAC: hmac-sha1;Comp: none
debug2: mac_setup: found hmac-sha1
debug1: REQUESTED ENC.NAME is 'aes256-ctr'
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 4096 8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
################################
debug2: dh_gen_key: priv key bits set: 272/512
debug2: bits set: 2037/4096
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 2068/4096
################################
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: monitor_read: checking request 4
debug3: mm_request_receive entering
debug3: mm_answer_sign
################################'debug3: mm_answer_sign: signature 400374f0(271)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug2: cipher_init: set keylen (16 -> 32)
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

[Steven Schweda]

> Im pretty sure its not reverse lookup which
> causes the problem [...]

Why?

> Ive also tried implementing /dev/random,
> which does not do the trick either.

How?

> So Im a bit lost.

Imagine what it's (or "its", if you prefer)
like for someone who knows even less about
what you actually did than you do.

[Eric SAUBIGNAC]

Bonjour,

"and its VERY slow before I get a loginprompt" .../... "Im pretty sure its not reverse lookup which causes the problem"

In my experience slow loginprompts are due to DNS configuration in about 200%

Just do a simple test with telnet. If loginprompt is also slow, IT IS a name resolution problem.

Eric

[Danny Petterson - DK]

Hi Gurus!

Ive tried to post an answer before, but apparently it didnt work - sorry.

First of all, thanx for your time - Im sorry if I agitated anyone (Steven), it was certainly not the idea.

Here goes some additionaly information:
The reason I dont think reverse lookup is the problem is:
- dig -x is answering as it is supposed to
- telnet is answering right away
- If i put -u0 for ssh-args in /etc/rc.config.d/sshd, it does not help in any way
- ssh to the IP is just as slow

Also I:
- Tried to comment out lines in the ssh_prng_cmds-file (the ones with timeout when running ssh-rand-helper)
- Installed the KRNG11i (/dev/random) product, but it did not do the trick either

Any suggestion will be greatly appreciated.

Thanx again.

Yours
Danny

[James R. Ferguson · Accepted solution]

Hi Danny:

> Im sorry if I agitated anyone (Steven), it was certainly not the idea.

Don't worry about that. Your question is certainly most welcome and the information you provided is enough to get started!

That said, Eric's first question of whether or not you see similar delays with simple Telnet is germane. I agree that if so, then DNS reverse-lookups might be an issue. If not, then:

What kind of server are you running? I see very long delays with PuTTy ssh connections on an old K-class running 11.11 with 200MHz processors. This is a nicely patched, up-to-date old piece of iron with the KRNG random number generator in place too. I don't see this behavior on a more modern rp5470 running identical software. Of course, its processors are 750MHz ones.

Regards!

...JRF...

[Danny Petterson - DK]

Hi James!

Damn!! Right on the spot! Its an old K460 with 180 Mhz CPU's. I have another 11.11. rp3440, where there is no problems at all.

Thans alot, it did not solve the problem, but it certainly did learn me what created the issue in the first place.

Thanx a bunch!

Take care.
Yours
Danny Petterson