Hi,

I have a problem connecting to my PC at work running OpenSSH, version
5.2.0.1.3 on Interix (a BSD like OS). Before a recent OS upgrade it
worked just fine but now sshd closes the connection immediately after
entering password during login. I have uninstalled, reinstalled and
rebooted... all to no avail. Below is the output from running the ssh
client with debug flags.

I have also tried this on my home PC where OpenSSH works fine. The
only obvious difference I can tell is that after the trace:

"debug1: permanently_set_uid: 197608/197121"

my work PC never gets to print the environment variables. It simply
proceeds to close the connection. On my home PC however all the
environment variables are being printed and it then enters interactive
mode as expected. I have not fiddled with the sshd configuration files
which are at their default settings. I am at a loss as to what has
gone wrong so any clues are gratefully received.

Many thanks,


Rob


LAMPREY+oeffner:~> ssh -vvv -p 9742 LAMPREY+oeffner@localhost
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 9742.
debug1: Connection established.
debug1: identity file /dev/fs/E/Users/oeffner/.ssh/identity type -1
debug1: identity file /dev/fs/E/Users/oeffner/.ssh/id_rsa type -1
debug1: identity file /dev/fs/E/Users/oeffner/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-
hellman-group-exchange-sha1,diffie-hellman-group1
4-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
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,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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-sha256,diffie-
hellman-group-exchange-sha1,diffie-hellman-group1
4-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
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: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 498/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [127.0.0.1]:9742
debug3: put_host_port: [localhost]:9742
debug3: check_host_in_hostfile: filename /dev/fs/E/Users/oeffner/.ssh/
known_hosts
debug3: check_host_in_hostfile: filename /usr/local/etc/
ssh_known_hosts
debug1: checking without port identifier
debug3: check_host_in_hostfile: filename /dev/fs/E/Users/oeffner/.ssh/
known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /dev/fs/E/Users/oeffner/.ssh/known_hosts:1
debug1: found matching key w/out port
debug2: bits set: 510/1024
debug1: ssh_rsa_verify: signature correct
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /dev/fs/E/Users/oeffner/.ssh/identity (0x0)
debug2: key: /dev/fs/E/Users/oeffner/.ssh/id_rsa (0x0)
debug2: key: /dev/fs/E/Users/oeffner/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,password,keyboard-
interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /dev/fs/E/Users/oeffner/.ssh/identity
debug3: no such identity: /dev/fs/E/Users/oeffner/.ssh/identity
debug1: Trying private key: /dev/fs/E/Users/oeffner/.ssh/id_rsa
debug3: no such identity: /dev/fs/E/Users/oeffner/.ssh/id_rsa
debug1: Trying private key: /dev/fs/E/Users/oeffner/.ssh/id_dsa
debug3: no such identity: /dev/fs/E/Users/oeffner/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-
interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
LAMPREY+oeffner@localhost's password:
debug3: packet_send2: adding 48 (len 68 padlen 12 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: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug1: permanently_set_uid: 197608/197121
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com
reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
Connection to localhost closed.
Transferred: sent 1712, received 2120 bytes, in 0.3 seconds
Bytes per second: sent 5776.0, received 7152.5
debug1: Exit status -1
LAMPREY+oeffner:~>

On Jan 5, 11:09=A0am, Rob <rob...@oeffner.net> wrote:
> Hi,
>
> I have a problem connecting to my PC at work running OpenSSH, version
> 5.2.0.1.3 on Interix (a BSD like OS). Before a recent OS upgrade it
> worked just fine but now sshd closes the connection immediately after
> entering password during login. I have uninstalled, reinstalled and
> rebooted... all to no avail. Below is the output from running the ssh
> client with debug flags.
>
> I have also tried this on my home PC where OpenSSH works fine. The
> only obvious difference I can tell is that after the trace:
>
> "debug1: permanently_set_uid: 197608/197121"
>
> my work PC never gets to print the environment variables. It simply
> proceeds to close the connection. On my home PC however all the
> environment variables are being printed and it then enters interactive
> mode as expected. I have not fiddled with the sshd configuration files
> which are at their default settings. I am at a loss as to what has
> gone wrong so any clues are gratefully received.
>
> Many thanks,

You did an OS upgrade. Did you recompile, to assure that your
libraries are properly integrated?

And note: Interix is *NOT* a "BSD like OS", at least according to its
manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.

And since you're apparently running Windows under the hood, which anti-
virus software are you running? McAfee, for example, can cause some
fascinating problems for SSH daemons due to kernel modifications which
are still active, even when every McAfee feature is disabled, until
you actually remove McAfee kicking and screaming from the system.

On Jan 6, 3:13=A0am, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Jan 5, 11:09=A0am, Rob <rob...@oeffner.net> wrote:
>
>
>
>
>
> > Hi,
>
> > I have a problem connecting to my PC at work running OpenSSH, version
> > 5.2.0.1.3 on Interix (a BSD like OS). Before a recent OS upgrade it
> > worked just fine but now sshd closes the connection immediately after
> > entering password during login. I have uninstalled, reinstalled and
> > rebooted... all to no avail. Below is the output from running the ssh
> > client with debug flags.
>
> > I have also tried this on my home PC where OpenSSH works fine. The
> > only obvious difference I can tell is that after the trace:
>
> > "debug1: permanently_set_uid: 197608/197121"
>
> > my work PC never gets to print the environment variables. It simply
> > proceeds to close the connection. On my home PC however all the
> > environment variables are being printed and it then enters interactive
> > mode as expected. I have not fiddled with the sshd configuration files
> > which are at their default settings. I am at a loss as to what has
> > gone wrong so any clues are gratefully received.
>
> > Many thanks,
>
> You did an OS upgrade. Did you recompile, to assure that your
> libraries are properly integrated?
>
> And note: Interix is *NOT* a "BSD like OS", at least according to its
> manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.
>
> And since you're apparently running Windows under the hood, which anti-
> virus software are you running? McAfee, for example, can cause some
> fascinating problems for SSH daemons due to kernel modifications which
> are still active, even when every McAfee feature is disabled, until
> you actually remove McAfee kicking and screaming from the system.- Hide q=
uoted text -
>
> - Show quoted text -

Thanks for your reply Nico. I agree that interix is a unix like
subsystem on top of the NT kernel. The OS upgrade I made was from
WinXP to Win7. Others running interix on Win7 seem not to have had any
problems with ssh. I just disabled the Windows firewall, uninstalled
McAfee antivirus and rebooted my work PC. The result is the same; sshd
immediately closes the connection.
I have not recompiled it but will take a look at it. Any other
suggestions?

Thanks,

Rob

Nico Kadel-Garcia <nkadel@gmail.com> writes:
> And note: Interix is *NOT* a "BSD like OS", at least according to its
> manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.

Close enough.  Last I checked, Interix was based on NetBSD.

DES
-- 
Dag-Erling Smørgrav - des@des.no

On Jan 6, 6:47=A0am, Dag-Erling Sm=F8rgrav <d...@des.no> wrote:
> Nico Kadel-Garcia <nka...@gmail.com> writes:
> > And note: Interix is *NOT* a "BSD like OS", at least according to its
> > manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.
>
> Close enough. =A0Last I checked, Interix was based on NetBSD.
>
> DES

No, it's really not, for profound legal reasons involving trademarks
and for techinical reasons involving the kernel. I can expect a direct
NetBSD variant to be POSIX compliant: I cannot expect a Microsoft
"full-featured POSIX and Unix environment subsystem" to actually
follow anyone's API's, including Microsoft's own published API's. And
as Rob pointed out, he upgraded the host OS, not Interix itself.

I would no more expect this to work properly with locally components
after a host OS upgrade than I'd expect OpenSSH compiled on RHEL 3 to
be certain to operate under an RHEL 5 kernel. Rob hopped from Windows
XP to Windows 7. There are just too many kernel changes between those
releases, especially since the intervening Windows Vista got skipped
entirely.

Rob? Definitely recompile. Which SSH or OpenSSH are you using?

On Jan 6, 6:06=A0am, Rob <rob...@oeffner.net> wrote:
> On Jan 6, 3:13=A0am, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>
>
>
> > On Jan 5, 11:09=A0am, Rob <rob...@oeffner.net> wrote:
>
> > > Hi,
>
> > > I have a problem connecting to my PC at work running OpenSSH, version
> > > 5.2.0.1.3 on Interix (a BSD like OS). Before a recent OS upgrade it
> > > worked just fine but now sshd closes the connection immediately after
> > > entering password during login. I have uninstalled, reinstalled and
> > > rebooted... all to no avail. Below is the output from running the ssh
> > > client with debug flags.
>
> > > I have also tried this on my home PC where OpenSSH works fine. The
> > > only obvious difference I can tell is that after the trace:
>
> > > "debug1: permanently_set_uid: 197608/197121"
>
> > > my work PC never gets to print the environment variables. It simply
> > > proceeds to close the connection. On my home PC however all the
> > > environment variables are being printed and it then enters interactiv=
e
> > > mode as expected. I have not fiddled with the sshd configuration file=
s
> > > which are at their default settings. I am at a loss as to what has
> > > gone wrong so any clues are gratefully received.
>
> > > Many thanks,
>
> > You did an OS upgrade. Did you recompile, to assure that your
> > libraries are properly integrated?
>
> > And note: Interix is *NOT* a "BSD like OS", at least according to its
> > manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.
>
> > And since you're apparently running Windows under the hood, which anti-
> > virus software are you running? McAfee, for example, can cause some
> > fascinating problems for SSH daemons due to kernel modifications which
> > are still active, even when every McAfee feature is disabled, until
> > you actually remove McAfee kicking and screaming from the system.- Hide=
 quoted text -
>
> > - Show quoted text -
>
> Thanks for your reply Nico. I agree that interix is a unix like
> subsystem on top of the NT kernel. The OS upgrade I made was from
> WinXP to Win7. Others running interix on Win7 seem not to have had any
> problems with ssh. I just disabled the Windows firewall, uninstalled
> McAfee antivirus and rebooted my work PC. The result is the same; sshd
> immediately closes the connection.
> I have not recompiled it but will take a look at it. Any other
> suggestions?
>
> Thanks,
>
> Rob

Ohhhh, one other thought. There is an undocumented sshd of "-r" in
OpenSSH, to prevent the use of re-exec. It's described for Windows XP
and McAfee issues at http://fixunix.com/ssh/73787-mcafee-cygwin-ssh.html.
I wonder if Windows 7 has the same sort of irksome protecton against
re-exec'ing that McAfee enabled and removed the option to turn it
off?.

On Jan 6, 7:00=A0pm, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Jan 6, 6:06=A0am, Rob <rob...@oeffner.net> wrote:
>
>
>
>
>
> > On Jan 6, 3:13=A0am, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>
> > > On Jan 5, 11:09=A0am, Rob <rob...@oeffner.net> wrote:
>
> > > > Hi,
>
> > > > I have a problem connecting to my PC at work running OpenSSH, versi=
on
> > > > 5.2.0.1.3 on Interix (a BSD like OS). Before a recent OS upgrade it
> > > > worked just fine but now sshd closes the connection immediately aft=
er
> > > > entering password during login. I have uninstalled, reinstalled and
> > > > rebooted... all to no avail. Below is the output from running the s=
sh
> > > > client with debug flags.
>
> > > > I have also tried this on my home PC where OpenSSH works fine. The
> > > > only obvious difference I can tell is that after the trace:
>
> > > > "debug1: permanently_set_uid: 197608/197121"
>
> > > > my work PC never gets to print the environment variables. It simply
> > > > proceeds to close the connection. On my home PC however all the
> > > > environment variables are being printed and it then enters interact=
ive
> > > > mode as expected. I have not fiddled with the sshd configuration fi=
les
> > > > which are at their default settings. I am at a loss as to what has
> > > > gone wrong so any clues are gratefully received.
>
> > > > Many thanks,
>
> > > You did an OS upgrade. Did you recompile, to assure that your
> > > libraries are properly integrated?
>
> > > And note: Interix is *NOT* a "BSD like OS", at least according to its
> > > manufacturer, Microsoft. It's a UNIX like subsystem for NT systems.
>
> > > And since you're apparently running Windows under the hood, which ant=
i-
> > > virus software are you running? McAfee, for example, can cause some
> > > fascinating problems for SSH daemons due to kernel modifications whic=
h
> > > are still active, even when every McAfee feature is disabled, until
> > > you actually remove McAfee kicking and screaming from the system.- Hi=
de quoted text -
>
> > > - Show quoted text -
>
> > Thanks for your reply Nico. I agree that interix is a unix like
> > subsystem on top of the NT kernel. The OS upgrade I made was from
> > WinXP to Win7. Others running interix on Win7 seem not to have had any
> > problems with ssh. I just disabled the Windows firewall, uninstalled
> > McAfee antivirus and rebooted my work PC. The result is the same; sshd
> > immediately closes the connection.
> > I have not recompiled it but will take a look at it. Any other
> > suggestions?
>
> > Thanks,
>
> > Rob
>
> Ohhhh, one other thought. There is an undocumented sshd of "-r" in
> OpenSSH, to prevent the use of re-exec. It's described for Windows XP
> and McAfee issues athttp://fixunix.com/ssh/73787-mcafee-cygwin-ssh.html.
> I wonder if Windows 7 has the same sort of irksome protecton against
> re-exec'ing that McAfee enabled and removed the option to turn it
> off?.- Hide quoted text -
>
> - Show quoted text -

Thanks for the reply. AFAIK Interix versions are fixed to the
particular WinOS with version 3.5 on XP, 6.0 on Vista and 6.1 on Win7.
I just tried starting sshd with the -r switch and the connection is
still being closed immediately after login. I also tried switching off
DEP on the Win7 PC to no avail. My PC at home where sshd works fine
runs Vista (with DEP and AVG). I'll try recompiling opnsshd on the
Win7 PC and see if at least I can locate what's going wrong and when.

thanks,

Rob

I've had some success today (finally). It seems that tinkering with
the configuration file /usr/local/etc/sshd_config helps. I've changed

UseLogin no
to

UseLogin yes

Shutting down and restarting sshd I am then able to login remotely.
But now ssh appears to invoke two shells and prompt twice for
passwords like this:

guppy:~ rdo20$ ssh LAMPREY+oeffner@lamprey
LAMPREY+oeffner@lamprey's password:
Password:
Welcome to the SUA utilities.
Welcome to the SUA utilities.
DISPLAY=localhost:0.0
LAMPREY+oeffner:~>

Anybody there who has an idea of what is going on?
For the sake of it below is a snippet of the ssh login session with
debug output from when first prompted for password until I enter exit
which closes the interactive ssh session:

debug1: Next authentication method: password
LAMPREY+oeffner@lamprey's password:
debug3: packet_send2: adding 48 (len 68 padlen 12 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: Requesting [email=no-more-sessions@openssh.com]no-more-
sessions@openssh.com[/email]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Password:debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
Welcome to the SUA utilities.
Welcome to the SUA utilities.
DISPLAY=localhost:0.0
LAMPREY+oeffner:~> exit
logout
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com
reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 7 c -1
Connection to lamprey closed.
Transferred: sent 2192, received 2856 bytes, in 89.0 seconds
Bytes per second: sent 24.6, received 32.1
debug1: Exit status 0
guppy:~ rdo20$


Clearly this is odd!

Rob

So no one has a clue as to what might be the cause of this problem?
Surely it shouldn't be necessary to have "UseLogin yes" set in the
sshd_config file. Moreover being prompted twice for passwords
indicates something is not right.

Rob