Mail Archives: cygwin/2008/05/12/19:03:39
> -----Original Message-----
> From: Igor Peshansky
> Sent: Monday, May 12, 2008 4:30 PM
> To: Schutter, Thomas A.
> Subject: RE: Unable to run sshd under a domain sshd_server account
[SOLVED]
>
> On Mon, 12 May 2008, Schutter, Thomas A. wrote:
>
> > > -----Original Message-----
> > > From: Schutter, Thomas A.
> > > Sent: Monday, May 12, 2008 9:52 AM
> > > To: 'cygwin AT XXXXXX DOT XXX'
>
> <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
>
> > > Subject: Unable to run sshd under a domain sshd_server account
> > >
> > > I am having problems setting up sshd to run under a domain
> sshd_server
> > > account instead of a local sshd_server account.
> > > [snip]
> > > But when I login via ssh:
> > > $ echo $USER
> > > tschutter
> > > $ echo $USERNAME
> > > sshd_server
>
> Yes -- Windows does not understand user impersonation and does not
> allow
> real user switching. So what sshd does is invoke processes with the
> appropriate token privileges for the user it's impersonating, while
> updating internal Cygwin data structures, but still running as
> sshd_server. So Cygwin sees the right user (in its internal state),
> but
> Windows processes, of course, don't.
Interesting. I suspected this, but this is the first time that I have
seen this explicitly stated.
> > > The application event log has this error message:
> > > 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 2068: service `sshd'
> > > failed: signal 11 raised.
>
> Oops -- a segfault. This is definitely a bug somewhere -- no matter
> what,
> sshd should not segfault.
Agreed.
> > In the other thread, Larry Hall pointed me to the FAQ
> > http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
> > suggestions was to "provide your password to a net use command". I
> was
> > unable to make that work, because "net use" never asks for my
> password:
> > $ net use \\other\f$
> > System error 67 has occurred.
> >
> > The network name cannot be found.
>
> See "net help use":
> The syntax of this command is:
> NET USE
> [devicename | *] [\\computername\sharename[\volume] [password | *]]
> ...
> password Is the password needed to access the shared
> resource.
> * Produces a prompt for the password. The password is
> not displayed when you type it at the password
> prompt.
>
> So, you need to type "net use '\\other\f$' \*" (note the
escaped/quoted
> '*'), and it'll prompt you for the password.
OK. So on a console cygwin shell:
$ net use '\\other\f$'
The command completed successfully.
But when run in a ssh shell (using the sshd_server account):
$ net use '\\other\f$' \*
Type the password for \\zoom\f$: System error 1326 has occurred.
Logon failure: unknown user name or bad password.
Same thing happens with:
$ net use '\\other\f$' '*'
$ net use '\\other\f$' "*"
--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -