Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3A0F0B5A.AB935D85@ece.gatech.edu>
Date: Sun, 12 Nov 2000 16:27:54 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
Subject: Re: [ANNOUNCEMENT] Updated: OpenSSH-2.3.0p1
References: <200011081557 DOT KAA17388 AT rtl DOT cygnus DOT com> <3A0A0BE6 DOT 2EEFEF2F AT ece DOT gatech DOT edu> <3A0A77AD DOT B20B171B AT redhat DOT com> <3A0AFE80 DOT A2C85E2A AT ece DOT gatech DOT edu> <3A0B2408 DOT 1A15CA6D AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:
> 
> Charles Wilson wrote:
> > Okay.  It seems to be a false alarm.  My original tests used the
> > graphical sftp client from ssh.com, which does an 'ls' as its first
> > operation -- and as you point out, 'ls' doesn't work without your latest
> > cygwin patch.
> 
> I'm glad that it helps.
> 
> >   However, from linux:
> 
> I would be interested if you can duplicate the below timeout problem
> (which doesn't occur to me) when compiling OpenSSH-2.3.0p1 on your
> Linux box and connecting from the Linux ssh.com sftp to the Linux
> OpenSSH sftp-server... I can't imagine a reason why this timeout
> problem should be a cygwin specific problem.
> 

Okay -- 
  Linux
  ssh.com's ssh-2.3.0 sftp client
    --- connect to ---->
  Linux
  OpenSSH-2.3.0p1 sftp-server

works fine.  ls, get, put, all okay.

But, 
  Linux
  ssh.com's ssh-2.3.0 sftp client
    --- connect to ---->
  Cygwin-1.1.5-7
  OpenSSH-2.3.0p1 sftp-server

kinda works: 'put', 'get' are okay, but 'ls' gives a listing of the
directory and then quits.  log from the OpenSSH-sftp-server side appears
below.  This is contrary to my retraction above; but at least both
Linux-ssh.com-sftp-2.3.0-client and Windows-ssh.com-sftp-2.3.0-client
work identically now: both print a listing and then disconnect.  The
windows version always disconnects immediately -- because it
automatically does the verboten 'ls'; the linux version is okay since
you *can* use it without doing an 'ls' (but when you do, then it
dies...) 

--Chuck

~ > /usr/sbin/sshd -d
debug1: sshd version OpenSSH_2.3.0p1
debug1: Seeding random number generator
debug1: read DSA private key done
debug1: Seeding random number generator
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
debug1: Seeding random number generator
debug1: Seeding random number generator
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 192.168.0.1 port 1319
debug1: Client protocol version 2.0; client software version 2.3.0 SSH
Secure Shell (non-commercial)
debug1: match: 2.3.0 SSH Secure Shell (non-commercial) pat ^2\.[23]\.0 

Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.3.0p1
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit: diffie-hellman-group1-sha1
debug1: got kexinit: ssh-dss
debug1: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none
debug1: got kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour,none
debug1: got kexinit: hmac-sha1,hmac-md5,hmac-md5-96,none
debug1: got kexinit: hmac-sha1,hmac-md5,hmac-md5-96,none
debug1: got kexinit: none,zlib
debug1: got kexinit: none,zlib
debug1: got kexinit: 
debug1: got kexinit: 
debug1: first kex follow: 1 
debug1: reserved: 0 
debug1: done
debug1: kex: client->server 3des-cbc hmac-sha1 none
debug1: kex: server->client 3des-cbc hmac-sha1 none
debug1: Wait SSH2_MSG_KEXDH_INIT.
debug1: bits set: 500/1024
debug1: bits set: 532/1024
debug1: sig size 20 20
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: done: KEX2.
debug1: userauth-request for user cwilson service ssh-connection method
none
debug1: attempt #1
Failed none for cwilson from 192.168.0.1 port 1319 ssh2
debug1: userauth-request for user cwilson service ssh-connection method
publickey
debug1: attempt #2
debug1: test whether pkalg/pkblob are acceptable
debug1: seteuid 1002: Not owner
Failed publickey for cwilson from 192.168.0.1 port 1319 ssh2
debug1: userauth-request for user cwilson service ssh-connection method
none
debug1: attempt #3
Failed none for cwilson from 192.168.0.1 port 1319 ssh2
debug1: userauth-request for user cwilson service ssh-connection method
password
debug1: attempt #4
Accepted password for cwilson from 192.168.0.1 port 1319 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 100000 max
8192
debug1: open session
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: confirm session
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request subsystem
reply 1
subsystem request for sftp
debug1: subsystem: exec() /usr/sbin/sftp-server
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 188
debug1: session_exit_message: session 0 channel 0 pid 188
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: output open -> closed
debug1: channel 0: close_write
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: session_free: session 0 pid 188
debug1: channel 0: read<=0 rfd 7 len -1
debug1: channel 0: read failed
error: channel 0: internal error: we do not read, but chan_read_failed
for istate 8
debug1: channel 0: send close
debug1: channel 0: rcvd close
debug1: channel 0: full closed2
debug1: channel_free: channel 0: status: The following connections are
open:
  #0 server-session (t4 r0 i8/0 o128/0 fd 7/7)

Connection closed by remote host.
debug1: Calling cleanup 0x4201f4(0x0)
debug1: Calling cleanup 0x4149e4(0x0)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com