This is the mail archive of the
mailing list for the Cygwin project.
Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 8 Jan 2010 15:59:57 +0100
- Subject: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)
- References: <email@example.com>
- Reply-to: cygwin at cygwin dot com
On Jan 7 14:33, Greg Fury wrote:
> - Domain user that is a local administrator AND has the local
> administrator as primary group in /etc/passwd, - login with key
> authentication works fine.
> - Domain user that is a local administrator WITHOUT the local
> administrator as primary group in /etc/passwd, - cannot login with key
> - Local user regardless of primary group in /etc/passwd or local group
> setting - login with key authentication works fine
> - Local user with key authentication and not a member of local
> administrators fails when an argument is passed on the command line:
> linux$ ssh user@host1-w2k3 pwd
> 20 [main] sshd 244 D:\cygwin-1.7\usr\sbin\sshd.exe: *** fatal
> error - could not load user32, Win32 error 1114
I can't reproduce this one, but I can reproduce the other problem
with pubkey authentication reported in this thread:
# ssh foo@bar
Last login: [...]
1 [main] -bash 6832 C:\cygwin\bin\bash.exe: *** fatal error -
couldn't dynamically determine load address for 'WSAGetLastError'
(handle 0xFFFFFFFF), Win32 error 126
Connection to bar closed.
The problem is this:
If you're running in a domain, then the account running the sshd service
must be a member of the domain as well. Instead of creating a local
cyg_server account, you must create a domain account called cyg_server
with the specific rights required to create a user token, add it to the
/etc/passwd file of the machine on which you want to install sshd, and
*then* run ssh-host-config on that machine.
If you did that, the ssh-host-config script will note that such an
account exists in /etc/passwd and will offer to use that account for the
Ok, back to square one. Assume you're using a local cyg_server account,
and you're using the default method of switching the user context
without password according to Method 1(*). That means, Cygwin has to
create a user token from scratch.
Now you try to ssh into the machine with a domain account. cyg_server
is a local machine account. Thus it is not known to the DC. However,
the incoming ssh connection requests a logon for a domain account.
To be able to create a matching user token, sshd has to access the DC
and fetch the user information for that account. But the DC doesn't
know the cyg_server account under which the calling process is running,
so it refuses to deliver the information for security reasons.
So cyg_server gets no information about that account. It has to fall
back to the information in /etc/passwd and /etc/group. From that it
constructs a crippled user token which only contains the SID of the user
and the SID of the primary group, plus the well-known SIDs for the LOCAL
and the INTERACTIVE group.
Now let's have a look into the default permissions of ws2_32.dll on
a Windows Server 2003:
$ cacls C:/WINDOWS/system32/ws2_32.dll
Oh, too bad. None of these groups is in the user token of the just
logged on user. Bingo.
So, bottom line is, the most important thing to keep in mind is that you
must use a domain cyg_server account to run sshd under, to be able to
correctly log on with domain accounts using password-less logon Method 1(*).
Additionally you have to create a domain policy so that the special
permissions required to create a user token(*) are propagated to the
machines which are supposed to run sshd. Fortunately, since that's how
domains work, you only have to do this once on the DC.
Nevertheless, having said that, I'm wondering if we should always add
the local BUILTIN\Users group to a user token, if we failed to fetch the
user information from the DC...
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple