Question about cygwin sshd and StrictModes

Discussion:

Matt Berney

2003-12-10 00:22:56 UTC

I have a question about the /etc/sshd_config file under cygwin. I have cygwin v1.5.5 and openssh

Cygwin Package Information
Package Version
cygwin 1.5.5-1
cygwin-doc 1.3-6

openssh 3.7.1p2-1
openssl 0.9.7c-1
openssl-devel 0.9.7c-1
openssl096 0.9.6j-1

What is the recommended technique to allow for ssh without passwords? Here is my procedure:
1) on the server, ssh-host-config
2) on the server, ssh-keygen -d (no passkey e.g. blank)
3) on the server, net start sshd

4) on the client, ssh-keygen -d (no passkey e.g. blank)
5) on the client, scp ~/.ssh/id_dsa.pub qar50s1:

6) on the server, cat id_dsa.pub >> .ssh/authorized_keys2

All of this works just fine until I change the /etc/sshd_config file to set StrictModes to yes

[sshd_config]
StrictModes yes

What do I have to do to make this work? Here is the debug output:

OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to qar50s1 [10.11.50.1] port 22.
debug1: Connection established.
debug1: identity file /home/mberney/.ssh/identity type -1
debug1: identity file /home/mberney/.ssh/id_rsa type -1
debug1: identity file /home/mberney/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'qar50s1' is known and matches the RSA host key.
debug1: Found key in /home/mberney/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mberney/.ssh/identity
debug1: Trying private key: /home/mberney/.ssh/id_rsa
debug1: Offering public key: /home/mberney/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
***@qar50s1's password:

Matt Berney

2003-12-10 00:49:05 UTC

Permalink

Here is the debug info from a 'successful' attempt (i.e. StrictModes no)

$ ssh -v ***@qar50s1 id
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to qar50s1 [10.11.50.1] port 22.
debug1: Connection established.
debug1: identity file /home/mberney/.ssh/identity type -1
debug1: identity file /home/mberney/.ssh/id_rsa type -1
debug1: identity file /home/mberney/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'qar50s1' is known and matches the RSA host key.
debug1: Found key in /home/mberney/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mberney/.ssh/identity
debug1: Trying private key: /home/mberney/.ssh/id_rsa
debug1: Offering public key: /home/mberney/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: id
uid=37278(root) gid=10513(Domain Users) groups=544(Administrators),545(Users),10512(Domain Admins),10513(Domain Users)
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.7 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

-----Original Message-----
From: Matt Berney
Sent: Tuesday, December 09, 2003 4:23 PM
Cc: Matt Berney
Subject: Question about cygwin sshd and StrictModes
I have a question about the /etc/sshd_config file under cygwin. I have cygwin v1.5.5 and openssh
Cygwin Package Information
Package Version
cygwin 1.5.5-1
cygwin-doc 1.3-6
openssh 3.7.1p2-1
openssl 0.9.7c-1
openssl-devel 0.9.7c-1
openssl096 0.9.6j-1
1) on the server, ssh-host-config
2) on the server, ssh-keygen -d (no passkey e.g. blank)
3) on the server, net start sshd
4) on the client, ssh-keygen -d (no passkey e.g. blank)
6) on the server, cat id_dsa.pub >> .ssh/authorized_keys2
All of this works just fine until I change the /etc/sshd_config file to set StrictModes to yes
[sshd_config]
StrictModes yes
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to qar50s1 [10.11.50.1] port 22.
debug1: Connection established.
debug1: identity file /home/mberney/.ssh/identity type -1
debug1: identity file /home/mberney/.ssh/id_rsa type -1>
debug1: identity file /home/mberney/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'qar50s1' is known and matches the RSA host key.
debug1: Found key in /home/mberney/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mberney/.ssh/identity
debug1: Trying private key: /home/mberney/.ssh/id_rsa
debug1: Offering public key: /home/mberney/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

Larry Hall

2003-12-10 03:39:33 UTC

Permalink

Post by Matt Berney
I have a question about the /etc/sshd_config file under cygwin. I have cygwin v1.5.5 and openssh
Cygwin Package Information
Package Version
cygwin 1.5.5-1
cygwin-doc 1.3-6
openssh 3.7.1p2-1
openssl 0.9.7c-1
openssl-devel 0.9.7c-1
openssl096 0.9.6j-1
What is the recommended technique to allow for ssh without passwords?

Read /usr/share/doc/Cygwin/openssh.README

Post by Matt Berney
1) on the server, ssh-host-config
2) on the server, ssh-keygen -d (no passkey e.g. blank)
3) on the server, net start sshd
4) on the client, ssh-keygen -d (no passkey e.g. blank)
6) on the server, cat id_dsa.pub >> .ssh/authorized_keys2
All of this works just fine until I change the /etc/sshd_config file to set StrictModes to yes
[sshd_config]
StrictModes yes
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to qar50s1 [10.11.50.1] port 22.
debug1: Connection established.
debug1: identity file /home/mberney/.ssh/identity type -1
debug1: identity file /home/mberney/.ssh/id_rsa type -1
debug1: identity file /home/mberney/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'qar50s1' is known and matches the RSA host key.
debug1: Found key in /home/mberney/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mberney/.ssh/identity
debug1: Trying private key: /home/mberney/.ssh/id_rsa
debug1: Offering public key: /home/mberney/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
--
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/

Matt Berney

2003-12-10 17:17:23 UTC

Permalink

Thanks for the no-help. I have already read all relevant documentation that I could find. That is the reason for posting a message to the group. In the future, if you wish to be helpful, please offer more than RTFM.

-----Original Message-----
From: Larry Hall [mailto:cygwin-***@cygwin.com]
Sent: Tuesday, December 09, 2003 7:40 PM
To: Matt Berney; ***@cygwin.com
Subject: Re: Question about cygwin sshd and StrictModes

Read /usr/share/doc/Cygwin/openssh.README

Ehud Karni

2003-12-10 19:00:30 UTC

Permalink

I don't exactly know what Larry meant, but if you read the "Fucking"
manual as you claim, you either missed or misunderstood the following
(from the man pages of sshd_config(5) ):

StrictModes
Specifies whether sshd should check file modes and ownership of
the user's files and home directory before accepting login. This
^^^^^^
is normally desirable because novices sometimes accidentally
leave their directory or files world-writable. The default is
``yes''.

Which is in plain English: check the permissions of your Home (~/)
and your ssh (~/.ssh) directories. Your home directory must NOT be
writable by others (not even from your group) and the ~/.ssh should
not be readable by others (because you may have your private keys
there).

Ehud.

- --
Ehud Karni Tel: +972-3-7966-561 /"\
Mivtach - Simon Fax: +972-3-7966-667 \ / ASCII Ribbon Campaign
Insurance agencies (USA) voice mail and X Against HTML Mail
http://www.mvs.co.il FAX: 1-815-5509341 / \
GnuPG: 98EA398D <http://www.keyserver.net/> Better Safe Than Sorry

Larry Hall

2003-12-10 21:05:44 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't exactly know what Larry meant, but if you read the "Fucking"
manual as you claim, you either missed or misunderstood the following
StrictModes
Specifies whether sshd should check file modes and ownership of
the user's files and home directory before accepting login. This
^^^^^^
is normally desirable because novices sometimes accidentally
leave their directory or files world-writable. The default is
``yes''.
Which is in plain English: check the permissions of your Home (~/)
and your ssh (~/.ssh) directories. Your home directory must NOT be
writable by others (not even from your group) and the ~/.ssh should
not be readable by others (because you may have your private keys
there).
Ehud.

Colorful language aside, I think Ehud brings up a good point. While
this is a port of openssh to Cygwin, all the regular documentation for
openssh is valid and should be consulted when investigating an issue.
These guidelines are valid across all platforms. In this case, the
prose from the man-page that Ehud quotes seems quite relevant and his
suggestion very sound.

Ehud, you should be careful about replying to the list if your
reply would expose somebody's email address in the body of a message.
You'll note I've obscured Matt's email address that came from your reply.

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

Steven Hartland

2003-12-10 22:06:08 UTC

Permalink

I've been having a number of issue with cygwin since install.
I've gone though all the usual sources before asking but cant
seem to get any closer to solving the issue.
Im currently seeing two seperate problems which both turn out
to be file permission based.
Setup:
Windows XP, NTFS, CYGWIN=ntsec, cygwin 1.5.5-1

Issues:
1. rsync partial file updates fails with:
rename failed ... permission denied
2. execution of an application extracted under cygwin fails
random error ( it cant access its dll in the local dir )

From my investigations is appears that cygwin is maintaining

the "default" permissions that should be inherited from the
current dir / parent directory. The core cause for both the errors
appears to be the lack of access to the created files by "SYSTEM".

All the standard permission for the current user / or owner of
the files seems to be correct but its the "hidden" permissions
or lack of that are causing the issues.

So where do I go from here? Has anyone else seen this
behaviour, knows a fix?

Regards
Steve

Larry Hall

2003-12-10 23:30:42 UTC

Permalink

Post by Steven Hartland
I've been having a number of issue with cygwin since install.
I've gone though all the usual sources before asking but cant
seem to get any closer to solving the issue.
Im currently seeing two seperate problems which both turn out
to be file permission based.
Windows XP, NTFS, CYGWIN=ntsec, cygwin 1.5.5-1
rename failed ... permission denied
2. execution of an application extracted under cygwin fails
random error ( it cant access its dll in the local dir )

From my investigations is appears that cygwin is maintaining

the "default" permissions that should be inherited from the
current dir / parent directory. The core cause for both the errors
appears to be the lack of access to the created files by "SYSTEM".
All the standard permission for the current user / or owner of
the files seems to be correct but its the "hidden" permissions
or lack of that are causing the issues.
So where do I go from here? Has anyone else seen this
behaviour, knows a fix?

There's been some traffic on this list about similar-sounding problems.
You can look in the email archives for some discussion and solutions there.
If you're intent on getting some personal feedback, I'm going to suggest
that you start by reading and complying with
<http://cygwin.com/problems.html>. This will give the base-line of
information from which someone can assess your installation.

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

Steven Hartland

2003-12-11 00:51:23 UTC

Permalink

Yer I had a read though the history in the mailing lists similar
problems where mentioned but never any solutions that I could
find.

Double checking problems.html looks like the only thing I
missed is the cygcheck.out so I've attached.

Did a bit more testing and heres a quick one that I believe shows
the issue:

getfacl.exe games/
# file: games/
# owner: steven
# group: None
user::rwx
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:mpukgame:rwx
mask:rwx
other:---
default:user::---
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:mask:rwx
[***@eisenguard]/usr/local: cd games
[***@eisenguard]/usr/local/games: touch 1
[***@eisenguard]/usr/local/games: getfacl.exe 1
# file: 1
# owner: steven
# group: None
user::rw-
group::r--
mask:rwx
other:r--

As you can see the file 1 was created with out SYSTEM,
Administators group access where it is my belief that as
they are set as "default" they should be inherited by any
files created under them. This belief is enhanced by creating
another file through explorer -> new ( text doc )
which yields:
# file: 2
# owner: steven
# group: None
user::rwx
group::---
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

As an aside to this issue this issue it might be helpful
to have the ablity to configure cygwin to set default
acl's on files i.e. add SYSTEM access as without it
major issues can occur. This however would be
strictly and ENH not a DR.

Steve

----- Original Message -----
From: "Larry Hall" <cygwin-***@cygwin.com>
To: "Steven Hartland" <***@barrysworld.com>; <***@cygwin.com>
Sent: Wednesday, December 10, 2003 11:30 PM
Subject: Re: file permissions issues on creation with cygwin 1.5.5-1?

Post by Larry Hall

From my investigations is appears that cygwin is maintaining

the "default" permissions that should be inherited from the
current dir / parent directory. The core cause for both the errors
appears to be the lack of access to the created files by "SYSTEM".
All the standard permission for the current user / or owner of
the files seems to be correct but its the "hidden" permissions
or lack of that are causing the issues.
So where do I go from here? Has anyone else seen this
behaviour, knows a fix?

There's been some traffic on this list about similar-sounding problems.
You can look in the email archives for some discussion and solutions there.
If you're intent on getting some personal feedback, I'm going to suggest
that you start by reading and complying with
<http://cygwin.com/problems.html>. This will give the base-line of
information from which someone can assess your installation.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746

Larry Hall

2003-12-11 02:59:44 UTC

Permalink

You've shown that files created with Windows have somewhat different
permissions than files created with Cygwin. That doesn't support your
conjecture that Cygwin utilities cannot access the files it creates.

I don't see anything odd in your cygcheck output so you might want to
try to run the offending commands with strace and, if the problem still
happens, see if there's anything in the output that indicates where
things are going wrong. If you can't see anything, send the output* to
the list with the exact command you used to create the problem. Maybe
someone else will be able to see the problem area and/or reproduce it.

Larry

* Don't send the strace output to the list if it's larger than, say,
50K-100K. Just post it on some sight and send the URL where the file
is to the list.

Post by Steven Hartland
Yer I had a read though the history in the mailing lists similar
problems where mentioned but never any solutions that I could
find.
Double checking problems.html looks like the only thing I
missed is the cygcheck.out so I've attached.
Did a bit more testing and heres a quick one that I believe shows
getfacl.exe games/
# file: games/
# owner: steven
# group: None
user::rwx
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:mpukgame:rwx
mask:rwx
other:---
default:user::---
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:mask:rwx
# file: 1
# owner: steven
# group: None
user::rw-
group::r--
mask:rwx
other:r--
As you can see the file 1 was created with out SYSTEM,
Administators group access where it is my belief that as
they are set as "default" they should be inherited by any
files created under them. This belief is enhanced by creating
another file through explorer -> new ( text doc )
# file: 2
# owner: steven
# group: None
user::rwx
group::---
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---
As an aside to this issue this issue it might be helpful
to have the ablity to configure cygwin to set default
acl's on files i.e. add SYSTEM access as without it
major issues can occur. This however would be
strictly and ENH not a DR.
Steve
----- Original Message -----
Sent: Wednesday, December 10, 2003 11:30 PM
Subject: Re: file permissions issues on creation with cygwin 1.5.5-1?

Post by Larry Hall

From my investigations is appears that cygwin is maintaining

the "default" permissions that should be inherited from the
current dir / parent directory. The core cause for both the errors
appears to be the lack of access to the created files by "SYSTEM".
All the standard permission for the current user / or owner of
the files seems to be correct but its the "hidden" permissions
or lack of that are causing the issues.
So where do I go from here? Has anyone else seen this
behaviour, knows a fix?

There's been some traffic on this list about similar-sounding problems.
You can look in the email archives for some discussion and solutions there.
If you're intent on getting some personal feedback, I'm going to suggest
that you start by reading and complying with
<http://cygwin.com/problems.html>. This will give the base-line of
information from which someone can assess your installation.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746

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

Steven Hartland

2003-12-11 03:57:25 UTC

Permalink

----- Original Message -----

Post by Larry Hall
You've shown that files created with Windows have somewhat different
permissions than files created with Cygwin. That doesn't support your
conjecture that Cygwin utilities cannot access the files it creates.

Im not sure on the details of the rsync one yet but the archive one is clear.
If I have a tar.gz with with files in when I expand these using cygwin due
to the issue with inheriance the files get owned strictly by the current user /
group. Now when another user comes to access said files they cant
even though they should as the permissions should have been inherited.

Post by Larry Hall
I don't see anything odd in your cygcheck output so you might want to
try to run the offending commands with strace and, if the problem still
happens, see if there's anything in the output that indicates where
things are going wrong. If you can't see anything, send the output* to
the list with the exact command you used to create the problem. Maybe
someone else will be able to see the problem area and/or reproduce it.

Will look at getting a reproducable senario up and running then will
report back for the rsync issue. I was forced to use other means to
correct the original situation I was seeing the error in.

Post by Larry Hall
* Don't send the strace output to the list if it's larger than, say,
50K-100K. Just post it on some sight and send the URL where the file
is to the list.

Hehe I don't think I would do that even on an off day :P

Thanks for your time so far Larry appreciated.

Steve

Larry Hall

2003-12-11 04:25:52 UTC

Permalink

Post by Steven Hartland
----- Original Message -----

Will look at getting a reproducable senario up and running then will
report back for the rsync issue. I was forced to use other means to
correct the original situation I was seeing the error in.

Post by Larry Hall
* Don't send the strace output to the list if it's larger than, say,
50K-100K. Just post it on some sight and send the URL where the file
is to the list.

Hehe I don't think I would do that even on an off day :P
Thanks for your time so far Larry appreciated.
Steve

Steve, please make sure you don't quote people's email addresses in
the body of your replies. This goes to the list and becomes fodder
for spam harvesters.

OK, so for your example using 'tar', who is "another user"? How do you
become this other user? Is this user a local Windows account? Is this
user accessing the file via Windows tools or Cygwin tools? If that user
is using Cygwin tools, is the user in /etc/passwd? Does it share any
groups in common with 'root' (this is, by the way, not a good name for
a user - Cygwin is instituting a 'root' user with uid 0 for better UNIX
compatibility)?

Cygwin doesn't create files with the "inherited" permissions of Windows.
But it doesn't have to do that in order for others to be able to access
the files. I've always had inheriting of Windows permissions turned off
here. No problems. What groups are listed for 'root' as far as Windows
is concerned?

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

Larry Hall (RFK Partners, Inc)

2003-12-10 20:57:23 UTC

Permalink

Clearly, you have not read the document I pointed to, or not read it
carefully, since the "procedure" you describe below does not use
ssh-user-config. While your procedure may do everything that is covered
in the README (implicitly or explicitly), it would be wise for you to
review your procedure against the prescribed method and make sure there
are no differences. From a help-desk perspective, this list relies heavily
on the codified knowledge of these scripts. No one is likely to spend much
time theorizing what your problem might be without a known baseline. These
scripts and tools are there to automate the process of installation with
best practices. You're free not to use them but you can't expect those of
us who monitor and respond on this list to debug everyone's custom
installation. Sorry if that's what you were expecting. So maybe this
amounts to "no-help" from your perspective. If that's the case, you probably
won't be happy with any response you get from this list on this subject
at least.

Larry

Post by Matt Berney
Thanks for the no-help. I have already read all relevant documentation that I could find. That is the reason for posting a message to the group. In the future, if you wish to be helpful, please offer more than RTFM.
-----Original Message-----
Sent: Tuesday, December 09, 2003 7:40 PM
Subject: Re: Question about cygwin sshd and StrictModes

Read /usr/share/doc/Cygwin/openssh.README

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