1.7.1: problem with public key authentication on domain accounts

[Thomas Nisbach]

Thomas Nisbach <nisbach <at> cityweb.de> writes:

> 
> Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes:
> 
> > 
> > On 01/06/2010 07:35 AM, Andrew Ng wrote:
> > > I've also been seeing problems with sshd (and inetd) since upgrading to 
> 1.7.1.
> > >> From my investigations it does look to be something to do with 
launching 
> via
> > > cygrunsrv. If I manually start sshd then everything seems to work fine.
> > 
> > While this is an interesting data point, I want to reiterate that starting 
> > 'sshd' in
> > this way is unsupported by this list, which means if you have problems in 
the
> > future with 'sshd', reports sent to this list about them are likely to 
fall 
> on
> > "deaf ears".  The configuration of 'sshd' under Cygwin is involved, which 
is 
> why
> > the process is automated by configuration scripts.  No one is forced to use
> > these scripts but those that don't understand the complexities behind them
> > shouldn't be ignoring them.  So please, do not take the report above as
> > advice about how 'sshd' should be run under Cygwin.  If you do, you do so
> > at your own peril.
> > 
> I'll be back and like to give you some more information about what I found. 
> But first I have to clarify two things:
> 1. on my system I just use local accounts, not domain accounts (as at top of 
> these thread)
> 2. I runned ssh-host-config with/without privilege separation and got 
> different problems, described above
> 
> NOW THE INTERESTING FACTS I FOUND: 
> * Configuring sshd via ssh-host-config, running under SYSTEM account, 
enables 
> me to log in as SYSTEM with private key but logging in as any other user 
leads 
> to the error message, described at top of this thread.
> 
> * Running 'sshd' under another user's account allow me to log in as this 
user, 
> but now longer as SYSTEM
> 
> Therefore I conclude (but needs further investigation), that the problem is 
> somewhere in fork/setuid.
> Perhaps this problem does not raise if sshd is runned in an environment with 
> another configuration - i try to find out.
> 
> 
Here is my SOLUTION and what I additionally found:
Using LSA-package (running cyglsa-config script and reboot) is (the only?) 
solution (Larry recommended, too)!
I read Corinna's message (also linked by CYGWIN User's Guide, 
http://cygwin.com/ml/cygwin-developers/2006-11/msg00000.html). Here she 
mentions that it is necessary to use LSA or a special user account like 
sshd_server. Before updating to CYGWIN 1.7.1 I did not use LSA or a special 
user account. Everything run fine since mid of 2006 and all CYGWIN updates in 
between. I still do not understand what the difference in 1.7.1 is. Therefore 
here my investigations:

NO SOLUTIONS for me (on a XP home edition):
* updating /etc/passwd and/or /etc/group
* installing a second CYGWIN from scratch (minimal installation) and just 
running ssh-host-config
* setting up a password for my local user (I don't use a password on my home 
box). But this made login via password possible (instead of pub/priv key).

What I found (without LSA configured):
Changing my login shell to /usr/bin/telnet made it possible to make some 
tests. Telnet was started by sshd on my login host but it e.g. was not 
possible to run local commands via "!" command (...could not load ws2_32, 
Win32 error 126). Via Sysinternals process explorer I found a lot of 
privileges missing on the forked sshd and telnet process. I guess the 
privilege to modify the PATH is missing because PATH of the telnet process was 
empty (resulting in the error message above?)

Conclusion: Should there be a recommandation in the User's guid to use LSA 
when updating to 1.7.1 and using services like SSH?






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