Can't use key authentication on x64 Server 2003 R2

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Can't use key authentication on x64 Server 2003 R2

Gordon Messmer
Since upgrading to Cygwin 1.7, I'm no longer able to use key
authentication on one of several Windows systems.  All of the working
systems are 32 bit installs, the one which isn't working is 64 bit.

The problem only affects key authentication.  Password authentication
still works properly.

To minimize variables, I started by removing Cygwin entirely from this
host.  I deleted C:\cygwin, removed the old sshd and sshd_server user
accounts, and removed those accounts' rights in the Local Security
Policy tool.  Cygwin was then installed again.

I don't think it matters, but I also noticed that all of these hosts are
domain members.  All of the other (working) hosts opted to use the sshd
and sshd_server domain accounts, while the failing host is using local
accounts.  I'm not sure how Cygwin interacts with Windows when creating
accounts, and what would cause it to use domain accounts on some hosts
but local accounts on others.  I previously tried removing the local
accounts and using mkpasswd.exe to load the domain accounts into
/etc/passwd.  That attempt also failed, but in a completely different
manner.  ssh-host-config complained that the local SAM didn't recognize
the accounts or something like that.  I can do so again if that
information is wanted.

When the client connects, I get this error:

    # ssh -i id_rsa [hidden email]
    Last login: Tue Dec 29 13:17:34 2009 from backup.xxx.local
           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 exch64.xxx.local closed.

Event viewer records an apparent success:

    The description for Event ID ( 0 ) in Source ( sshd ) cannot be
    found. The local computer may not have the necessary registry
    information or message DLL files to display messages from a remote
    computer. You may be able to use the /AUXSOURCE= flag to retrieve
    this description; see Help and Support for details. The following
    information is part of the event: sshd: PID 5872: Accepted publickey
    for gordon from 192.168.99.4 port 49012 ssh2.

The output of "cygcheck -s -v -r" and "ssh-host-config" are attached.
Please let me know if there is any additional information that I can
provide to help diagnose and correct the problem.

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

cygcheck.out (24K) Download Attachment
cygwin-ssh-host-config.txt (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Csaba Raduly-2
On Wed, Dec 30, 2009 at 4:56 AM, Gordon Messmer <> wrote:
> Since upgrading to Cygwin 1.7, I'm no longer able to use key authentication
> on one of several Windows systems.  All of the working systems are 32 bit
> installs, the one which isn't working is 64 bit.
.....
> When the client connects, I get this error:
>
>   # ssh -i id_rsa [hidden email]
>   Last login: Tue Dec 29 13:17:34 2009 from backup.xxx.local
>          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 exch64.xxx.local closed.

If I understand this correctly, it is the ssh client which quits
abruptly. Error 126 is "The notorious error 126 (ERROR_MOD_NOT_FOUND)
when loading DLL/DSO's in Win32" (first hit when googling "Win32 error
126"). However, WSAGetLastError is in ws2_32.dll, which is part of
Windows. But, being a 32-bit dll in a 64-bit Windows, maybe it's in
another directory which is not on the path. Check the folder of
ws2_32.dll

Were you connecting from exch64 to exch64 ?

Hope this helps,
Csaba
--
Life is complex, with real and imaginary parts

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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Gordon Messmer
On 12/30/2009 12:56 AM, Csaba Raduly wrote:

>
> If I understand this correctly, it is the ssh client which quits
> abruptly. Error 126 is "The notorious error 126 (ERROR_MOD_NOT_FOUND)
> when loading DLL/DSO's in Win32" (first hit when googling "Win32 error
> 126"). However, WSAGetLastError is in ws2_32.dll, which is part of
> Windows. But, being a 32-bit dll in a 64-bit Windows, maybe it's in
> another directory which is not on the path. Check the folder of
> ws2_32.dll
>
> Were you connecting from exch64 to exch64 ?
>    

I'd also seen one list member draw that conclusion, but for the life of
me I can't see why.  I'm connecting from a Linux host, and the error
appears to be printed by Cygwin's bash.exe.

bash.exe doesn't appear to be linked to that dll on either host.  I do
notice that /cygdrive/c/WINDOWS/system32 appears before  
/cygdrive/c/WINDOWS/sysWOW64 in the PATH.  I know nothing about Windows'
linker or loader, so I don't know if that could be a problem.  Is there
any way to change it system-wide for Cygwin?  On the broken 64 bit host:

$ ldd /bin/bash.exe
     kernel32.dll => /cygdrive/c/WINDOWS/syswow64/kernel32.dll (0x7d4c0000)
     ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7d600000)
     kernel32.dll => /cygdrive/c/WINDOWS/syswow64/kernel32.dll (0x7d4c0000)
     cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
     ADVAPI32.DLL => /cygdrive/c/WINDOWS/syswow64/ADVAPI32.DLL (0x7d1e0000)
     RPCRT4.dll => /cygdrive/c/WINDOWS/syswow64/RPCRT4.dll (0x7da20000)
     Secur32.dll => /cygdrive/c/WINDOWS/syswow64/Secur32.dll (0x7d8d0000)
     cygintl-8.dll => /usr/bin/cygintl-8.dll (0x6f5c0000)
     cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x674c0000)
     cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f00000)
     cygreadline7.dll => /usr/bin/cygreadline7.dll (0x6afc0000)
     cygncurses-9.dll => /usr/bin/cygncurses-9.dll (0x6db80000)
     USER32.dll => /cygdrive/c/WINDOWS/syswow64/USER32.dll (0x7d930000)
     GDI32.dll => /cygdrive/c/WINDOWS/syswow64/GDI32.dll (0x7d800000)
$ ls -l /cygdrive/c/WINDOWS/system32/ws2_32.dll
-rwxrwx---+ 1 Administrators SYSTEM 83456 2007-02-18 04:00
/cygdrive/c/WINDOWS/system32/ws2_32.dll
$ ls -l /cygdrive/c/WINDOWS/syswow64/ws2_32.dll
-rwxrwx---+ 1 Administrators SYSTEM 83456 2007-02-18 04:00
/cygdrive/c/WINDOWS/syswow64/ws2_32.dll
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Program Files/Support
Tools/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program
Files/ATI Technologies/ATI Control
Panel/:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/Microsoft/Exchange Server/bin:/cygdrive/c/Program
Files/Microsoft/Exchange
Server/Scripts:/cygdrive/c/WINDOWS/sysWOW64:/cygdrive/c/Program Files
(x86)/ExchangeMapi/:/bin


On a working 32 bit host:

$ ldd /bin/bash
     ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c800000)
     kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x77e40000)
     cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
     ADVAPI32.DLL => /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x7d1e0000)
     RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77c50000)
     Secur32.dll => /cygdrive/c/WINDOWS/system32/Secur32.dll (0x76f50000)
     cygintl-8.dll => /usr/bin/cygintl-8.dll (0x6f5c0000)
     cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x674c0000)
     cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f00000)
     cygreadline7.dll => /usr/bin/cygreadline7.dll (0x6afc0000)
     cygncurses-9.dll => /usr/bin/cygncurses-9.dll (0x6db80000)
     USER32.dll => /cygdrive/c/WINDOWS/system32/USER32.dll (0x77380000)
     GDI32.dll => /cygdrive/c/WINDOWS/system32/GDI32.dll (0x77c00000)
$ ls -l /cygdrive/c/WINDOWS/system32/ws2_32.dll
-rwxrwx---+ 1 Administrators SYSTEM 83456 2007-02-17 06:03
/cygdrive/c/WINDOWS/system32/ws2_32.dll



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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Gordon Messmer
Following advise that appeared for another user, I tried to run
rebaseall on the 64 bit Windows host.  It failed:

    $ rebaseall
    ReBaseImage (/usr/bin/cyggcc_s-1.dll) failed with last error = 6

Maybe this is related to the ssh with keys failure?


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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Yaakov (Cygwin/X)
On 31/12/2009 12:35, Gordon Messmer wrote:
> Following advise that appeared for another user, I tried to run
> rebaseall on the 64 bit Windows host. It failed:
>
> $ rebaseall
> ReBaseImage (/usr/bin/cyggcc_s-1.dll) failed with last error = 6

That means there is a process running besides rebaseall.  rebaseall must
be run from a dash shell with no other processes -- including services
-- running.


Yaakov

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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Gordon Messmer
On 12/31/2009 10:41 AM, Yaakov (Cygwin/X) wrote:
>
> That means there is a process running besides rebaseall.  rebaseall
> must be run from a dash shell with no other processes -- including
> services -- running.

I started bash from the start menu and ran "exec dash".  "ps ax" showed
no other cygwin processes, and sshd had been stopped.  rebaseall
complained before I'd done those things but not after.

I see now that "exec" doesn't do in cygwin what it does in Unix.  "bash"
was still running.  I started "dash" from a cmd prompt, and after
fiddling with PATH, TEMP and TMP environment variables, I was able to
run rebaseall.

For the record, rebaseall doesn't correct the problem with sshd and key
authentication.  bash still dies:
   1 [main] -bash 6832 C:\cygwin\bin\bash.exe: *** fatal error -
    couldn't dynamically determine load address for 'WSAGetLastError'

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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Christopher Faylor-8
On Thu, Dec 31, 2009 at 02:20:41PM -0800, Gordon Messmer wrote:

>On 12/31/2009 10:41 AM, Yaakov (Cygwin/X) wrote:
>>
>> That means there is a process running besides rebaseall.  rebaseall
>> must be run from a dash shell with no other processes -- including
>> services -- running.
>
>I started bash from the start menu and ran "exec dash".  "ps ax" showed
>no other cygwin processes, and sshd had been stopped.  rebaseall
>complained before I'd done those things but not after.
>
>I see now that "exec" doesn't do in cygwin what it does in Unix.

exec works like linux for everything but the first started cygwin
prcess.  If you're trying to rebase bash you really do need to start
dash by itself.

cgf

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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Gordon Messmer
In reply to this post by Gordon Messmer
For the time being, I've reinstalled Cygwin 1.5 on the problematic
host.  It still works as well as it ever did.


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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Larry Hall (Cygwin)
On 12/31/2009 07:33 PM, Gordon Messmer wrote:
> For the time being, I've reinstalled Cygwin 1.5 on the problematic host.
>   It still works as well as it ever did.

Oh good.  1.5 must be the new b20.

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

Reply | Threaded
Open this post in threaded view
|

Re: Can't use key authentication on x64 Server 2003 R2

Greg Fury
In reply to this post by Gordon Messmer
I've got a very similar issue on a 32-bit win 2003 32-bit machine.
Cygwin 1.5 works fine.  I was hoping to deploy 1.7 for some ssh
integration with my unix hosts, rather than install 1.5 which is now
considered a "legacy" package.

Fresh install of Cygwin 1.7
Only additional packages installed are ssh, vim and their dependencies.
Using privilege separation

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

- 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




--

-Greg

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

Reply | Threaded
Open this post in threaded view
|

Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Corinna Vinschen-2
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
> authentication.
>
> - 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
sshd service.

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
  C:\WINDOWS\system32\ws2_32.dll BUILTIN\Users:R
                                 BUILTIN\Power Users:R
                                 BUILTIN\Administrators:F
                                 NT AUTHORITY\SYSTEM:F

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


HTH,
Corinna


(*) http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1


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

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Greg Fury
Thank you for the quick and comprehensive response!  When
troubleshooting Windows, I feel like I have blinders on.  Thanks for
opening my eyes.

I will give this technique a try.

-Greg


On Fri, Jan 8, 2010 at 9:59 AM, Corinna Vinschen
<[hidden email]> wrote:

>
>
> > 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
> sshd service.
>
> 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
>  C:\WINDOWS\system32\ws2_32.dll BUILTIN\Users:R
>                                 BUILTIN\Power Users:R
>                                 BUILTIN\Administrators:F
>                                 NT AUTHORITY\SYSTEM:F
>
> 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...
>
>
> HTH,
> Corinna
>
>
> (*) http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
>
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>



--

-Greg

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Greg Fury
In reply to this post by Corinna Vinschen-2
Just wondering why this worked under 1.5 ?

-Greg


On Fri, Jan 8, 2010 at 9:59 AM, Corinna Vinschen
<[hidden email]> wrote:

> 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
>> authentication.
>>
>> - 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
> sshd service.
>
> 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
>  C:\WINDOWS\system32\ws2_32.dll BUILTIN\Users:R
>                                 BUILTIN\Power Users:R
>                                 BUILTIN\Administrators:F
>                                 NT AUTHORITY\SYSTEM:F
>
> 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...
>
>
> HTH,
> Corinna
>
>
> (*) http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
>
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>



--

-Greg

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Corinna Vinschen-2


Please, don't http://cygwin.com/acronyms/#TOFU


On Jan  8 14:53, Greg Fury wrote:
> Just wondering why this worked under 1.5 ?

1.5 fetched the group list using an incorrect method, leading
accidentally to a working result in this scenario.


Corinna

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Gordon Messmer
In reply to this post by Corinna Vinschen-2
On 01/08/2010 06:59 AM, Corinna Vinschen wrote:
> I can't reproduce this one, but I can reproduce the other problem
> with pubkey authentication reported  in this thread:
...

I appreciate the time you took to explain this problem.  I've been
working on it for a while, and still can't get it right.

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

I've created a "cyg_server" account on my domain controller and added it
to the password file using:

mkpasswd -d -u cyg_server >> /etc/passwd

First I tried granting the required permissions manually in the domain
policy.  When that didn't work, I used "editrights" as in
cygwin-service-installation-helper.sh to set the rights in the local
policy.  As far as I can tell, I get identical results.

Rights during my most recent test were:

$ editrights.exe -l -u cyg_server
SeAssignPrimaryTokenPrivilege
SeCreateTokenPrivilege
SeTcbPrivilege
SeServiceLogonRight
SeDenyRemoteInteractiveLogonRight

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

Hopefully I did something as simple as adding the account to the
password file incorrectly.  When I run ssh-host-config, I get the
following warning:

*** Warning: cyg_server is in /etc/passwd, but the local
*** Warning: machine's SAM does not know about cyg_server.
*** Warning: Perhaps cyg_server is a pre-existing domain account.
*** Warning: Continuing, but check if this is ok.

Regardless, I can use the account and sshd will run.  When I log in with
a password, I get a shell, but I see this warning:

  1 [main] sshd 2724 spawn_guts: CreateWindowStation failed, Win32 error 5

If I log in with a key, the server just drops the connection.  The
(Linux) client reports:
Connection closed by 192.168.99.6

The server's event log indicates:

The description for Event ID ( 0 ) in Source ( sshd ) cannot be found.
The local computer may not have the necessary registry information or
message DLL files to display messages from a remote computer. You may be
able to use the /AUXSOURCE= flag to retrieve this description; see Help
and Support for details. The following information is part of the event:
sshd: PID 6632: fatal: seteuid 11287: Permission denied.

The event viewer indicates that the user is DOMAIN\cyg_server, which is
the same username that appears in the Local Security Settings admin tool.

Does anyone have any specific advice for using a domain member account
(DOMAIN\cyg_server) to run sshd?  Without that, it seems I can't run
Cygwin 1.7's sshd with key authentication.

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Corinna Vinschen-2
On Jan 24 16:43, Gordon Messmer wrote:

> On 01/08/2010 06:59 AM, Corinna Vinschen wrote:
> >I can't reproduce this one, but I can reproduce the other problem
> >with pubkey authentication reported  in this thread:
> ...
>
> I appreciate the time you took to explain this problem.  I've been
> working on it for a while, and still can't get it right.
>
> >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.
>
> I've created a "cyg_server" account on my domain controller and
> added it to the password file using:
>
> mkpasswd -d -u cyg_server >> /etc/passwd
>
> First I tried granting the required permissions manually in the
> domain policy.  When that didn't work, I used "editrights" as in
> cygwin-service-installation-helper.sh to set the rights in the local
> policy.  As far as I can tell, I get identical results.
>
> Rights during my most recent test were:
>
> $ editrights.exe -l -u cyg_server
> SeAssignPrimaryTokenPrivilege
> SeCreateTokenPrivilege
> SeTcbPrivilege
> SeServiceLogonRight
> SeDenyRemoteInteractiveLogonRight

The cyg_server user is hopefully in the Administrators group...

Here's what I did.  I created cyg_server as admin account in the domain,
then I created a global policy which adds the cyg_server user to the
following user rights:

  Act as part of the operating system (SeTcbPrivilege)
  Create a token object               (SeCreateTokenPrivilege)
  Replace a process level token       (SeAssignPrimaryTokenPrivilege)

At last I made sure the global policy gets propagated to all domain
machines.  That's all.  From this time on I could use the domain
cyg_sever user on all my domain member machines, assuming I added it to
/etc/passwd before starting ssh-host-config.


Corinna

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Reini Urban
2010/1/25 Corinna Vinschen:

> On Jan 24 16:43, Gordon Messmer wrote:
>> On 01/08/2010 06:59 AM, Corinna Vinschen wrote:
>> >I can't reproduce this one, but I can reproduce the other problem
>> >with pubkey authentication reported  in this thread:
>> ...
>>
>> I appreciate the time you took to explain this problem.  I've been
>> working on it for a while, and still can't get it right.
>>
>> >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.
>>
>> I've created a "cyg_server" account on my domain controller and
>> added it to the password file using:
>>
>> mkpasswd -d -u cyg_server >> /etc/passwd
>>
>> First I tried granting the required permissions manually in the
>> domain policy.  When that didn't work, I used "editrights" as in
>> cygwin-service-installation-helper.sh to set the rights in the local
>> policy.  As far as I can tell, I get identical results.
>>
>> Rights during my most recent test were:
>>
>> $ editrights.exe -l -u cyg_server
>> SeAssignPrimaryTokenPrivilege
>> SeCreateTokenPrivilege
>> SeTcbPrivilege
>> SeServiceLogonRight
>> SeDenyRemoteInteractiveLogonRight
>
> The cyg_server user is hopefully in the Administrators group...
>
> Here's what I did.  I created cyg_server as admin account in the domain,
> then I created a global policy which adds the cyg_server user to the
> following user rights:
>
>  Act as part of the operating system (SeTcbPrivilege)
>  Create a token object               (SeCreateTokenPrivilege)
>  Replace a process level token       (SeAssignPrimaryTokenPrivilege)
>
> At last I made sure the global policy gets propagated to all domain
> machines.  That's all.  From this time on I could use the domain
> cyg_sever user on all my domain member machines, assuming I added it to
> /etc/passwd before starting ssh-host-config.

Can we add this to the FAQ please.

How to setup sshd for mixed local/domain accounts?
...
--
Reini Urban
http://phpwiki.org/           http://murbreak.at/

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

Reply | Threaded
Open this post in threaded view
|

Re: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

Corinna Vinschen-2
On Jan 25 12:11, Reini Urban wrote:

> 2010/1/25 Corinna Vinschen:
> > Here's what I did.  I created cyg_server as admin account in the domain,
> > then I created a global policy which adds the cyg_server user to the
> > following user rights:
> >
> >  Act as part of the operating system (SeTcbPrivilege)
> >  Create a token object               (SeCreateTokenPrivilege)
> >  Replace a process level token       (SeAssignPrimaryTokenPrivilege)
> >
> > At last I made sure the global policy gets propagated to all domain
> > machines.  That's all.  From this time on I could use the domain
> > cyg_sever user on all my domain member machines, assuming I added it to
> > /etc/passwd before starting ssh-host-config.
>
> Can we add this to the FAQ please.

I added a longish FAQ entry to CVS.


Corinna

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

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