Re: More on SSH problems....

[Len Giambrone <frodo at mit dot edu>]

Stephen,

I have had similar problems with sshd and the latest dlls.  When sshd attempts
to do an setuid() call, it fails, for some unknown reason.  The user was in
the passwd file, and in fact it all worked until I had added an extra user to
the passwd file without restarting sshd.  That was the only thing that had changed.

I found this out by:

- running sshd under strace
and ultimately
- running sshd under gdb

It's for this reason that I'm still running 1.3.10-1.

I'd suggest trying one or all of these suggestions and seeing if it fixes your
problem.

                        -Len


"Stephen C. Biggs" <yyyyy50@hotpop.com> writes:

> 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" <yyyyy50@hotpop.com>
> > To: <cygwin@cygwin.com>
> > 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/

--
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/