ssh 3.6.1 connection closed by remote host

[Saleet Jafri]

SSh used to work on my hpux 11.0 workstations until I upgraded to ssh 3.6.1. Now I get the error.
>ssh banach
jafri@banach's password:
Connection to banach closed by remote host.
Connection to banach closed.

I can ssh as root and sftp as the user, but cannot connect as a user.

When I try the -v to get more information I get
jafri@banach's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: channel 0: request shell
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to banach closed by remote host.
Connection to banach closed.
debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2506.4
debug1: Exit status -1

And ideas

[Steven E. Protter]

Secure Shell 3.6.2 ssh port of HP at http://software.hp.com is a fix for a serious security flaw.

will it help with this: Not sure, but you should go to it anyway. It fixes the flaw that forced the development of ssh 3.7

SEP

[Saleet Jafri]

Actually, the version you pointed me to is the one that broke my ssh. I upgraded due to the security problem with the previous version.

[Andrew Cowan]

I think that you need to add sshd to inetd.sec, and also check that if this version is setup to use wrappers, that the "/etc/hosts.allow" and "/etc/hosts.deny" are correctly configured.

Others problems are caused when the sshd user does not own the executables.

[Saleet Jafri]

I was going through the syslog and found the following error recorded after the SSH connection was refused:

Dec 22 10:42:12 banach sshd[8752]: fatal: mm_receive_fd: expected type 1 got 107
3863176

[RAC_1]

does it give any error code?

add -vvv for detailed debug and post thr results

[Saleet Jafri]

Everything proceeds well until after accpting the password. We are using RSA encryption (ie no hosts.allow ot deny).

jafri@banach's password:
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug1: channel 0: request pty-req
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 0
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 0
debug3: tty_make_modes: 13 0
debug3: tty_make_modes: 14 0
debug3: tty_make_modes: 16 0
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 1
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 1
debug3: tty_make_modes: 93 0
debug1: channel 0: request shell
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:\015
#0 client-session (t4 r0 i0/0 o0/0 fd 6/7)\015

debug3: channel_close_fds: channel 0: r 6 w 7 e 8
Connection to banach closed by remote host.
Connection to banach closed.
debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1321.9
debug1: Exit status -1

[RAC_1]

Exit status -1

goto /opt/ssh
There is directory called src uner /opt/ssh. (This source code for ssh.)

If I remeber correctly, there is a file like error.c or something similar.

This lists all error codes.

Check the error code and error description.

Hope this helps.

[James A. Donovan]

The mm_receive_fd error message in your syslog is related to the privilege separation code. Double check your setup and make sure that the server you're attempting to login to is correctly configured.

[RAC_1]

Found this on forum search.

Check
UsePrivilegeSeparation no
in sshd_config file. and restart.

[RAC_1]

Found this on forum search.

Check
UsePrivilegeSeparation no
in sshd_config file. and restart.

No points.

[Saleet Jafri]

Thanks to everyone for their responses.

The email by RAC: Set

UsePrivilegeSeparation no
in sshd_config file. and restart.

fixes the problem. It still does not explain why I have to make this change to the configuration file on some machines but not others (all running HPUX 11.0).

Does this setting have any security implications?

[G. Vrijhoeven]

Saleed,

It has security implications.

http://www.securityfocus.com/advisories/4242

and CERT:

http://www.cert.org/advisories/CA-2003-24.html

Gideon

[Andrew Cowan · Accepted solution]

I got a pam patch from these forums after having a similar problem. I rebuilt from source and the use-privilege-separation worked OK, so perhaps there's been an OS patch/fix that corrects this and its applied on some machines, but not others?

[Saleet Jafri]

Good suggestion

One lead I was pursuing involved using the sec_mgmt software to find out what patches were different on the maching that worked and the ones that did not. I found that the patch PHNE_28312 (inetd(1M) cumulative) was needed. This fixed the problem so I now can leave the priveledge separation on.

On a different system (11.22), I needed to install a new version of PAM to fix a slightly different problem. It did not allow a connection at all.

The problem is solved. Thanks to everyone for their time and help!