Re: ssh/pubkey authentication and use of subst

[Hannu Koivisto <azure at iki dot fi>]

Corinna Vinschen <corinna-cygwin@cygwin.com> writes:

> 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):

Ok.

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

Unfortunately the explicit form doesn't work for me via pubkey
authentication either, I get "System error 5 has occurred.  Access
is denied."  (return code is 2).

Precisely the same command works if I log in using password
authentication.

Both the client and the server machines run Windows XP SP2, openssh
is 4.7p1-2, cygwin 1.5.24-2.  sshd was set up with ssh-host-config.

I don't need shares, just subst, but I'd be happy to provide more
information and test things to help to figure this out.

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

subst also says "Access denied - <path>" (return code is 1).

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

Thanks for the explanation.

-- 
Hannu


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