From owner-ssh@clinet.fi Fri May 5 07:39:34 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by hutcs.cs.hut.fi (8.9.3/8.9.3) with ESMTP id HAA25984; Fri, 5 May 2000 07:39:34 +0300 (EET DST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id HAA18087 for ssh-outgoing; Fri, 5 May 2000 07:17:22 +0300 Received: from mail0.atl.bellsouth.net (mail0.atl.bellsouth.net [205.152.0.27]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id HAA18082 for ; Fri, 5 May 2000 07:17:20 +0300 Received: from whitetiger (adsl-78-141-76.atl.bellsouth.net [216.78.141.76]) by mail0.atl.bellsouth.net (3.3.5alt/0.75.2) with SMTP id AAA02439; Fri, 5 May 2000 00:13:49 -0400 (EDT) From: "Didier CONTIS" To: Cc: Subject: RE: Windows Client SFTP Date: Fri, 5 May 2000 00:16:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3911A1B6.3E68BE57@enterprise.arl.psu.edu> Sender: owner-ssh@clinet.fi Precedence: bulk I do experience the same exact symptoms. However, I can open a file transfer session to a linux box. Our Solaris box runs Solaris 2.7. I do not see any error message in the logging file of ssh2d. I have not tried yet to run it in debug mode. Didier. -----Original Message----- From: owner-ssh@clinet.fi [mailto:owner-ssh@clinet.fi]On Behalf Of Jeffrey Bailey Sent: Thursday, May 04, 2000 12:14 PM To: ssh@clinet.fi Subject: Windows Client SFTP We've been migrating users up to SSH 2.1 after the recent license change for universities. I have one user who cannot initiate an sftp session from his Windows NT platform (SSHWinSecureShell-21). The user can connect for a normal SSH to a Solaris 2.6 machine running SSH Secure Shell 2.1.0 (non-commercial version), using password for authentication. But when he tries to open a file transfer session, the connection immediately closes. The logs on the remote server do not show anything out of the ordinary. We can connect as a different user and have success with sftp from that same NT platform. If he moves to another NT machine, he still can't initiate sftp. He CAN, however, sit on a Sun machine and successfully use command-line sftp. The Suns on the network run NIS+ for logins, automounts of home directories and such. The user has tried connecting on a number of the platforms, including the host which has his home directory. Before he tried the command-line sftp, he didn't even have a .ssh2 directory in his home directory; neither did the successful sftp test account. Any ideas where to look for the culprit? -- Jeff Bailey 371 ARL Info Tech Associate PO Box 30 jdbailey@psu.edu State College, PA 16804 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Applied Research Laboratory, Penn State University