Incoming SSH connection on 11.11 leaves client with blank screen

[Eric Borgen]

Hi, I'm working on getting the first of several HPUX boxes set up with SSH to eventually replace telnet.

After installing version A.03.71 of the ssh package, when a remote ssh client connects to the server, the client is left with no prompt whatsoever. Just a blank screen.

From what I can tell, the server has authenticated the remote user, and lists them on when I do a 'w' or 'who'.

I can connect to the server locally from its own ssh client.

For a client remotely, I'm using QVT/Term ver. 5.2.0 on a WinXP workstation.

Below are some log excerpts to make the post unbearably long ;P
From Syslog, showing a remote user trying to connect, getting password wrong the 1st time, then getting it right:

Jun 23 11:39:23 HOSTNAME sshd[2811]: Server listening on 0.0.0.0 port 22.
Jun 23 11:41:12 HOSTNAME sshd[2970]: Failed password for username from 172.16.19.57 port 6803 ssh2
Jun 23 11:41:15 HOSTNAME sshd[2970]: Accepted password for username from 172.16.19.57 port 6803 ssh2

Now for the resulting text from starting SSHD with -ddd:

debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: read_server_config: filename /opt/ssh/etc/sshd_config
debug1: sshd version OpenSSH_3.7.1p2-pwexp26 [ HP-UX_Secure_Shell-A.03.71.000 ]
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 172.16.19.57 port 12904
debug1: Client protocol version 2.0; client software version OpenSSH_3.0.1p1
debug1: match: OpenSSH_3.0.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2-pwexp26
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 1588/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1648/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user username service ssh-connection method none
debug1: attempt 0 failures 0
debug1: allowed_user: entering
debug2: input_userauth_request: setting up authctxt for USERNAME
debug1: PAM: initializing for "USERNAME"
debug3: Trying to reverse map address 172.16.19.57.
debug1: PAM: setting PAM_RHOST to "172.16.19.57"
debug2: input_userauth_request: try method none
Failed none for USERNAME from 172.16.19.57 port 12904 ssh2
debug1: userauth-request for user USERNAME service ssh-connection method password
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method password
debug1: temporarily_use_uid: 101/20 (e=0/3)
debug1: restore_uid: 0/3
debug1: Kerberos password authentication failed: -1765328249
debug1: krb5_cleanup_proc called
debug3: do_pam_account: pam_acct_mgmt = 0
Accepted password for USERNAME from 172.16.19.57 port 12904 ssh2
debug1: Entering interactive session for SSH2.
debug2: fd 8 setting O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 32768 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/0
debug3: tty_parse_modes: SSH2 n_bytes 246
debug3: tty_parse_modes: ospeed 0
debug3: tty_parse_modes: ispeed 0
debug3: tty_parse_modes: 1 0
debug3: tty_parse_modes: 2 0
debug3: tty_parse_modes: 3 0
debug3: tty_parse_modes: 4 0
debug3: tty_parse_modes: 5 0
debug3: tty_parse_modes: 6 0
debug3: tty_parse_modes: 7 0
debug3: tty_parse_modes: 8 0
debug3: tty_parse_modes: 9 0
debug3: tty_parse_modes: 10 0
debug1: Ignoring unsupported tty mode opcode 12 (0xc)
debug3: tty_parse_modes: 13 0
debug3: tty_parse_modes: 14 0
debug1: Ignoring unsupported tty mode opcode 18 (0x12)
debug3: tty_parse_modes: 30 0
debug3: tty_parse_modes: 31 0
debug3: tty_parse_modes: 32 0
debug3: tty_parse_modes: 33 0
debug3: tty_parse_modes: 34 0
debug3: tty_parse_modes: 35 0
debug3: tty_parse_modes: 36 0
debug3: tty_parse_modes: 37 0
debug3: tty_parse_modes: 38 0
debug3: tty_parse_modes: 39 0
debug3: tty_parse_modes: 40 0
debug3: tty_parse_modes: 41 0
debug3: tty_parse_modes: 50 1
debug3: tty_parse_modes: 51 1
debug3: tty_parse_modes: 53 1
debug3: tty_parse_modes: 54 1
debug3: tty_parse_modes: 55 1
debug3: tty_parse_modes: 56 0
debug3: tty_parse_modes: 57 0
debug3: tty_parse_modes: 58 0
debug3: tty_parse_modes: 59 0
debug3: tty_parse_modes: 60 1
debug3: tty_parse_modes: 61 0
debug3: tty_parse_modes: 70 1
debug3: tty_parse_modes: 71 0
debug3: tty_parse_modes: 72 1
debug3: tty_parse_modes: 73 0
debug3: tty_parse_modes: 74 0
debug3: tty_parse_modes: 75 0
debug3: tty_parse_modes: 90 0
debug3: tty_parse_modes: 91 0
debug3: tty_parse_modes: 92 0
debug3: tty_parse_modes: 93 0
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM: setting PAM_TTY to "/dev/pts/0"
debug1: PAM: establishing credentials
debug2: fd 4 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug2: fd 10 is O_NONBLOCK
debug2: channel 0: read<=0 rfd 11 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed

End of long request for help,
(thanks in advance)
-Eric B.

[Sridhar Bhaskarla · Accepted solution]

Eric,

To confirm that it is not a problem with the server, try 'putty' and see if it exhibits the same behaviour.

http://www.chiark.greenend.org.uk/~sgtatham/putty/

-Sri

[Alzhy]

Did you install KRNG11i? Also, if you've another *NIX box - can you connect?

Other options:

1. Try using putty as suggested to make sure it is not your current SSH client on windows that is the problem

2. Wipe out /opt/ssh/etc/ssh_host* and do a /sbin/init.d/secsh stop/start.


HTH.

[Eric Borgen]

Thanks much for the suggestion of trying another SSH client, putty worked perfectly.

I use QVT to connect to our linux boxes and cisco equipment without any issues.

Any quick insights on why it fails in this instance?

(or maybe I'll just have to try to fall in love with Putty)

Thanks again,
-Eric

[Eric Borgen]

Nelson,
I didn't install the heavy duty RNG patch, because it seemed it was only designed to speed up SSH. Does it do other magical stuff?

In addition, wiping out my /opt/ssh/etc/ssh_host* is a bit of a drag, as I aparantly have to recreate the files. ./secsh start doesn't make them.
-Eric

[Sridhar Bhaskarla]

I never worked with QVT but it looks like your QVT is sending some mysterious characters to the HP box. Does it work well with telnet? Try the character set etc., etc., so that it can properly translate the data from HP.

For me love with putty is 'love at first sight'. ;-)

-Sri

[Alzhy]

Eric,
I suggest you read the QVT documentation throughly or get in touch with support. Mention to them the rev of SSH you're running on UNIX...