Message-Id: <200602012154.k11Ls8F8008015@tigris.pounder.sol.net>
From: cygwin AT trodman DOT com (Tom Rodman)
Reply-to: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: password-authenticated ssh session..;whoami shows OurSrvr064\sshd_server
In-reply-to: <20060201142658.GA2904@calimero.vinschen.de>
References: <200601311632 DOT k0VGW2em030961 AT tigris DOT pounder DOT sol DOT net> <20060201092026 DOT GD15572 AT calimero DOT vinschen DOT de> <200602011407 DOT k11E7FgQ006207 AT tigris DOT pounder DOT sol DOT net> <20060201142658 DOT GA2904 AT calimero DOT vinschen DOT de>
Date: Wed, 01 Feb 2006 15:54:07 -0600
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Wed 2/1/06 15:26 +0100 Corinna wrote:
> On Feb  1 08:07, Tom Rodman wrote:
> > On Wed 2/1/06 10:20 +0100 Corinna wrote:
> > > On Jan 31 10:32, Tom Rodman wrote:
> > > > Also notable, was that whoami shown: "OurSrvr064\sshd_server", instead of
> > > > "staffuser2".
> > > 
> > > That's normal for passwordless login.  
> > 
> > Sorry, I should have emphasized that when I ssh'd in, the password was
> > *manually* entered. Pls see this test case, which also refers to a
> > manually entered ssh password:
> > 
> >   http://cygwin.com/ml/cygwin/2006-02/msg00002.html
> > 
> > >From what Pierre Humblet posted in July:
> > 
> >   http://cygwin.com/ml/cygwin/2005-07/msg01344.html 
> > 
> > if the output of 'id -G' at the console differs from what you get in a
> > password authenticated ssh session, then that ssh session will not be
> > granted the appropriate rights. In our case we see 1 *additional*
> > local group when in the ssh session. What's special about that local
> > group is that it contains exactly 1 entry- "administrators". Also, pls
> > note that the user that is "sshing in" is in the "administrators" group,
> > so even though he is not a direct member of this group, 'id -G' reports
> > him as a member in an ssh session, but *not* at a non-ssh (console or
> > RDP, bash session)- hence the mismatch that Pierre warns about.
> > 
> > agin, pls see:
> > 
> >   http://cygwin.com/ml/cygwin/2006-02/msg00002.html
> 
> UI tried your testcase but I can't reproduce this.  I created a local
> group, added my admin account to it 

The problem shows up only if your account is *not* added to this
local group.  This local group should have just 1 entry - the
local administrators group, as in:

  $ net localgroup toss_at_will
  Alias name     toss_at_will
  Comment        test group

  Members

  -------------------------------------------------------------------------------
  Administrators
  The command completed successfully.

Then try sshing in as a user in the 'Administrators' group, using 
password authentication.  My hope is that you will see the problem.
I've only seen it on w2k+3, but have not tried it on w2k.

> and tried to ssh w/ password into
> the machine, in three different ways
> 
> - Group is missing in /etc/group
> - Group is in /etc/group, user is not present in gr_mem field.
> - Group is in /etc/group, user is present in gr_mem field.

my recent tests suggest I only need to update the gr_mem field for
groups w/a (default [no chg in offset]) cygwin gid > 9999

Let me stress that, to reproduce the problem, the new local group,
should have only 1 member - the 'Administrators' group. I know that
seems like a misuse of a local group; I think you can blame that on a
(FrontPage?) installer- some installer created the group on Monday.

> In all three cases a native whoami returned my correct user name.
> 
> However, I guess you should rework and rematch your group settings in
> /etc/group with the group settings in your Windows user database.  I
> can't tell what exactly is wrong, this is something you'll have to figure
> out by some experiments.  I assume your group settings are so that on
> setuid(), Cygwin finds that the group list does not match the group list
> returned in the user token it got from the LogonUser call (which is the
> Win32 equivalent for a password logon).  The additional requested groups
> can only be added by creating a new token.  This new token is created
> w/o password, since the LogonUser call will never return the correct
> group list.

thanks Corinna, not sure I understand that, but I will google a bit to 
help parse your explanation :->

> HTH,

--
*thank*-you again Corinna
Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/