ssh/pubkey authentication and use of subst
Wed Oct 31 12:22:00 GMT 2007
Corinna Vinschen <firstname.lastname@example.org> 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):
> $ 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>
> $ 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
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin