X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 30 Oct 2007 12:34:03 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: ssh/pubkey authentication and use of subst
Message-ID: <20071030113403.GM20400@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <lq1wbc6fw1 DOT fsf AT kalahari DOT s2 DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <lq1wbc6fw1.fsf@kalahari.s2.org>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Oct 30 12:44, Hannu Koivisto wrote:
> Based on earlier discussions on this list, it's apparently a known
> problem that when you use public key authentication, you are not
> authenticated "through windows", which means that you cannot map
> network shares, for example.

That's not right.   The problem is that you didn't logon using a
password and you are running in a foreign logon session.  The result is
that you have to use explicit identification when connecting to a share.
Assuming you are on machine or in domain BRAIN, user name PINKY.  When
you logged on using password authentication, everything is known to
identify and authorize you automatically to a server, so the following
works (assuming you *have* permissions to access the share):

  $ net use '\\server\share'

However, this doesn't work with pubkey authentication because your
authorization information is incomplete.  Therefore you have to
identify and authorize explicitely:

  $ net use '\\server\share' /user:'BRAIN\PINKY' <your-password>

or

  $ net use x: '\\server\share' /user:'BRAIN\PINKY' <your-password>

I have no idea why subst fails, though.  Must have something to do
with the below as well.

> If I understood correctly, when you log in using pubkey
> authentication, you basically are the user sshd runs as.  I have
> set up sshd without privilege separation so that would be the
> system account.

No. this has nothing to do with privilege separation.  It's a
Windows-only problem and it's more complex than that.

You are running as the user you have logged in as.  However, since no
Windows authentication took place, you don't get your own logon session.
You're running in the logon session of the user running sshd.  This
situation is wrongly evaluated by Windows, so that functions returning a
user name from a SID return the name of the user running sshd.  But the
application token does *not* grant you the permissions of the user
running sshd.  The token is still correct and only grant you the rights
your user account has.  The user and owner SIDs in the token are
correctly set to the SID of your own account.  Only the Windows
functions returning the user name do return the wrong name.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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