Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: Date: Mon, 05 Aug 2002 05:37:00 -0700 MIME-Version: 1.0 Subject: Re: More on SSH problems.... Message-ID: <3D4E0EFC.27040.101B6AB@localhost> In-reply-to: <003c01c23c75$de92fb90$6401a8c0@babylon5> Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body On 5 Aug 2002 at 7:47, Stephen Nordlund wrote: > Ok... now I'm confused. I wrote a little chroot how-to for cygwin. Stephen > was using that to base his thoughts on. I have to admit I use it for > passward authentication only but would like to setup up for PKI. Good luck... > > What is the proper way to use chroot? > What is the intendid use of chroot? > > Would there be any issues from chrooting from the passwd file via a shell > script? This is how I do it, as per your "howto". A security window is when sshd changes to the regular home directory of the user before it executes the script in the passwd fields. I guess this is logical, but I wish there were a way to have this behavior stopped. What happens if the home directory is not specified? > > Would there be a way to just chroot from the passwd file with out the shell > script? I don't think it matters if there was a way to stop the user from being placed in the regular home directory before executing the chroot script, that is, keep him in limbo until everything is chroot'ed... > > I guess this raises lots of questions for me. Remember what I wrote below. I now don't think my problem has anything to do with chroot. I think I am missing or have otherwise misconfigured something related to the Public Key Authentication, since taking chroot out of the mix still fails when I try Public Key. Corinna says that she is able to do this with a non-privileged user. I am totally dead in the water right now... been tearing my hair out about this for a few days now. > > ----- Original Message ----- > From: "Stephen C. Biggs" > To: > Sent: Monday, August 05, 2002 7:30 AM > Subject: Re: More on SSH problems.... > > > > 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/