Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Stephen C. Biggs" <yyyyy50 AT hotpop DOT com>
To: cygwin AT cygwin DOT com
Date: Mon, 05 Aug 2002 04:30:00 -0700
MIME-Version: 1.0
Subject: Re: More on SSH problems....
Message-ID: <3D4DFF48.23519.C45F09@localhost>
In-reply-to: <20020805131207.C3921@cygbert.vinschen.de>
References: <3D4DF5FD DOT 14250 DOT A012E2 AT localhost>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

On 5 Aug 2002 at 13:12, Corinna Vinschen 
wrote:

> On Mon, Aug 05, 2002 at 03:50:21AM -0700, Stephen C. Biggs wrote:
> > > So it's not the sshd server chroot'ing (which isn't implemented
> > > in the official ssh sources anyway).  The problem might be related
> > > to the fact that sshd and the shell script (another bash, that is)
> > > is still running not chrooted (using the Cygwin DLL in /bin) and
> > > the child bash is running using the Cygwin DLL in the chroot jail.
> > 
> > This sounds about right because it doesn't 
> > dump the connection until after it logs on.  But, 
> > it is the sshd server that dumps the connection, 
> > not ssh. (In the client side: "Connection to 
> 
> Sure.  Think about the situation.  Only ssh is running on the client
> side.  sshd -> bash -> script -> chroot -> bash is running server side.
> 
> > localhost closed by remote host").  This is now 
> > getting me very confused!  Unless something is 
> > being transmitted wrong, but it only seems to 
> > matter when public key authentication is being 
> > used.  Perhaps something needs the dll 
> > constantly in the client?  Bad news!
> 
> Patches gratefully...
> 

I'd consider it, if I knew where to even 
begin to start looking!

The thing is, I just tried it where I 
changed the line for the alternate 
user in /etc/passwd to NOT execute the 
chroot shell, rather /bin/bash, 
like normal.

Guess what, it still happens!  What's 
going on, here?  It seems related 
directly to public key authentication, 
because this now works if I allow 
PasswordAuthentication and 
PermitEmptyPassword.

Also, changing back to chroot'ing with 
the empty password, it works.  It 
MUST be related somehow to the 
public key authentication.  Something 
isn't configured right, or a file is in the 
wrong place or wrong 
permissions, or something... maybe 
SSHD doesn't like a different user 
than the real UID, but you say that this 
works for you...

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/