Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <018501c28748$ddeee050$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Harig, Mark A." <maharig AT idirect DOT net>, <cygwin AT cygwin DOT com>
References: <BADF3C947A1BD54FBA75C70C241B0B9E90B9CE AT ex02 DOT idirect DOT net>
Subject: Re: Is RSA authentication on SSH still broken?
Date: Fri, 8 Nov 2002 17:04:14 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Harig, Mark A. <maharig AT idirect DOT net> wrote:

>> On Thu, Nov 07, 2002 at 06:54:48PM -0500, Harig, Mark A. wrote:
>>> I must be missing a piece of information.  Setting the
>>> permissions of ~/.ssh to 700 causes ssh to require me
>>> to enter a password, that is, the encryption-key processing
>>> is failing.  Setting the permissions of ~/.ssh to 750 (if
>>> the group setting is SYSTEM) or to 755 (if the group setting
>>> is not SYSTEM) allows ssh to access the encryption-key files.
>>
>> Are you actually sure?  The permissions of directories don't
>> influence the permissions to the underlying files and directories
>> unless an administrator changes the setting of the above "Bypass
>> traverse checking"
>> user right.  Just to be sure I did check that yesterday on my
>> system so
>> I'm pretty confident.
>>
>> "Bypass traverse checking" is on by default for Everyone.  This is
>> annoyingly different from UNIX file systems from my point of view
>> but AFAIK professional Windows admins like it.  And since it's the
>> default and most users don't know what it's doing anyway, I don't
>> change it on my test system, too.
>>
>
> Hmm.  I'm sorry to be so dense, but:
>
>   1) I had never heard of "Bypass traverse checking" so I'm
>      pretty sure that I haven't changed it.

secpol.msc -> Local Policies -> User Rights Assignment

Could someone else? Because thats the only reason I can think of for the
behaviour you describe above.

>   2) Am I sure that I cannot use ~/.ssh if the mode is set to 700?
>      Changing the permissions for ~/.ssh to 750 or 755 has been
>      the solution for me and for a number of other users that
>      I've suggested it to.  Are we all doing something wrong? (a
>      possibility, of course)
>
>      The following script sets everything up for me (of course,
>      I respond to the ssh-keygen prompts):
>
>        #!/bin/bash
>        umask 0022 && \
>        chmod 700 ~ && \
>        mv ~/.ssh  ~/save.ssh && \
>        ssh-keygen -t rsa -C "some useful comment" -f ~/.ssh/id_rsa &&
>        \ cat ~/.ssh/id_rsa >> ~/.ssh/authorized_keys2
>
>      This causes ssh-keygen to create ~/.ssh with whatever permissions
>      it thinks are correct (i.e., 700).  (I'm running sshd on Win2K
> using
>      NTFS, Cygwin DLL 1.3.15, CYGWIN=ntsec, StrictMode=yes,
>      UsePrivilegeSeparation=yes)  After this script completes, I
>      attempt to connect to my ssh server from the machine that is
> running the server.
>      I can connect, but only if I provide my password.  Conversely, if
>      I set the permissions of ~/.ssh to 755, then I can connect
>      without providing my password.

One way to debug this is:

Install a second ssh service, to run with command line parameters -Dddde.
This sets debug mode (side effect: sshd dies after one connection).
Now try logging on, and verbose debug output will be written to
/var/log/<serviceshortname>.log by cygrunsrv.

Post the logs of a password and a pubkey logon. Hopefully that should reveal
what is happening.

Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/