Missing Registry entries under ssh after upgrade from 1.5 to 1.7

Eric Berge emberge@yahoo.com
Tue Mar 16 20:15:00 GMT 2010



I am using openssh to run software builds on a Windows 2003
system.

After a recent update of cygwin my builds started failing.
In both cases it appears that the Windows Registry is not as fully
populated for the ssh user as it was in previous versions of
cygwin/openssh.  Any help in guiding my analysis of this issue
would be greatly appreciated.

Note that in all tested cases, we are using ssh with explicit
passwords, no public-private key authentication is done at all.
The environment is in a domain and the build it done under a
domain user.  When the problem started to occur I found the
information about updating the sshd user to a domain user with
the required privileges but that did not change the behavior.
Note also that between the old and new systems the output of
the "c:/windows/system32/whoami /all" command is the same for
the user running under ssh.

The previous version of cygwin we had been running was installed
from a relatively up-to-date version as of February 2009 and we
installed the new version that failed in February 2010.  The
difference in the openssh versions is between 5.1p1-10 and 5.3p1-1
(although I also just tried 5.4p1-1 and it still exhibits the
same problems).  The cygwin package version changed from 1.5.25-15
to 1.7.1-1.

I noticed two effects of the change with regard to the Windows
Registry:

1. The HKCU Registry tree is very sparsely populated relative
   to previous versions of cygwin (details on this below).
   The first thing I noticed about this effect was that the
   HKCU\Network key didn't exist at all even though I had
   persistent drive mappings.

2. When I'm ssh'ed in there is no longer an entry
   HKU\S-1-5-... for the SID under which I am logged
   in (according to the output of "c:/windows/system32/whoami /all")

Problem 1 leads to "net use" not displaying any remembered
drive mappings.  In the past I used the output of this to do script
explicit "net use z: \\share..." commands to reconnect the drives.
This is a little annoying, but can be worked around by explicitly
calling "net use" to map the drives.  As mentioned below there
are likely to be other problems from this because the HKCU tree
is so sparsely populated relative to previous version of cywin,
but that this point that claim is unsubstantiated.

Problem 2, however, seems related to the fact that the
Windows "SignTool.exe" command now fails when we run it in an ssh
environment.  I used the sysinternals "Process Monitor" tool to
analyze this and it appears that a likely place that SignTool gets
into trouble is the attempt to open HKU/<SID> for the current user
and, as mentioned above, this fails since the entry does not exist.

One workaround for this problem is to remote desktop into this system
while you have a ssh session running.  The remote desktop session
populates the remaining parts of the Windows Registry and these
are immediate available to the pre-existing ssh session.  So just
by rdesktop'ing in after the fact, my build worked.  Of course
that's not a very good solution since I'm using ssh to do the build
so I don't have to rdesktop (more specifically that I can script
the build to be triggered from my Ubuntu system).

I also did a comparison of the output of "reg query HKCU /s" between
the ssh environment and a remote desktop environment and there is
quite a large piece of the HKCU registry that's missing relative to
the remote desktop environment.  This is also true in older versions
of cygwin (in particular in versions where we were able to build
successfully) however the difference between the ssh environments
HKCU tree and remote desktop's is considerably less in the older
version (more specifically, I ran diffstat on these and the
difference on the working system was about 100 lines vs around
10,000 lines of differences on the failing system).

So the question I have is whether some change in the last year or
so was intended to greatly limit the establishment of the Windows
Registry environment for users connecting via ssh.  If so, is there
anything we can configure to try to get this to behave the way it
did previously.

Although, more fundamentally, I'm looking for anything that can
help me understand this situation better as I might be looking
at the wrong things and asking the wrong questions.  In particular,
there might be a more fundamental reason for the lack of population
of the Windows Registry.

Perhaps a crisper question to start with would be whether
anyone running a current version of cygwin sees their SID listed
with the "reg query hku" command run under ssh (ensuring
that you are not also rdesktop'ed into the same box at that time).
If this is populated for you I'd be interested in any details of
your environment that might indicate a way I can make this work
in my environment.  My guess is that if HKU\<SID> is populated
perhaps the HKCU tree would be similarly well-populated, but that's
just a hope at this point.

Thanks in advance for any additional info you can give me or any
suggestions on how I can more fully diagnose the issue,

Eric Berge



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out
Type: application/octet-stream
Size: 128433 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20100316/d75cf40b/attachment.obj>
-------------- next part --------------
--
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


More information about the Cygwin mailing list