Re: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>]

On 2024-02-05 18:36, Eliot Moss via Cygwin wrote:
> On 2/5/2024 8:28 PM, Frank-Ulrich Sommer via Cygwin wrote:
>> On 05.02.2024 00:53, Frank-Ulrich Sommer via Cygwin wrote:
>>> I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux 
>>> machine. I have added the public key to 
>>> /cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from  
>>> /cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access 
>>> rights and mode of the .ssh directory (700 and belongs to user xxx) and the 
>>> authorized_keys file (600 and also belongs to user xxx) and also of the home 
>>> directory (had to change ownership).

Change the symlink from Cygwin home to your home, as symlinks have a+rwx perms, 
so you can not use one for .ssh:

	$ ln -sv `cygpath -aU "C:/Users/$USER"` /home/

>>> Now I get the following strange messages:
>>> [...]
>>> Feb  5 00:35:50 XXXXX sshd: PID 2798: debug1: temporarily_use_uid: 
>>> 197609/197121 (e=18/18)
>>> Feb  5 00:35:50 XXXXX sshd: PID 2798: debug1: trying public key file 
>>> /home/xxx/.ssh/authorized_keys
>>> Feb  5 00:35:50 XXXXX sshd: PID 2798: debug1: fd 5 clearing O_NONBLOCK
>>> Feb  5 00:35:50 XXXXX sshd: PID 2798: Authentication refused: bad ownership 
>>> or modes for directory /cygdrive/c/Users
>>> Feb  5 00:35:50 XXXXX sshd: PID 2798: debug1: restore_uid: 18/18
>>> [...]
>>> Why is cygsshd complaining about the Windows "Users" directory and not about 
>>> the directory of user xxx (/cygdrive/c/Users/xxx)? And how can I solve this?

>> Looking at the OpenSSH source code (on Github, not from Cygwin) I found a 
>> function "safe_path" that checks that the ownership and access modes for all 
>> path components are correct.  This relies on "platform_sys_dir_uid" which 
>> checks if a UID may own a system directory. The code checks for UID zero and 
>> might also accept an OS specific second value (PLATFORM_SYS_DIR_UID) but for 
>> Cygwin this seems not to be set. But I don't know where to find the source 
>> code for the exact version that is used in Cygwin and I'm unsure about build 
>> settings.

Run Cygwin setup and select package openssh Source checkbox to download the 
source package, or go to your Cygwin upstream mirror and download the source 
tarball shown in setup.ini prefixed with your nearest Cygwin mirror site e.g.

https://ftp.fau.de/cygwin/x86_64/release/openssh/openssh-9.6p1-1-src.tar.xz

Build settings are in the Cygwin package build control script definitions file 
openssh.cygport in the source tarball or build repo:

	https://cygwin.com/cgit/cygwin-packages/openssh/tree/openssh.cygport

...
	--disable-strip
	   --with-kerberos5=/usr
	       --libexecdir=/usr/sbin
	       --with-xauth=/usr/bin/xauth
	   --with-libedit
	   --with-security-key-builtin

>> A comment defines this a safe path as follows:
>> "This is defined as all components of the path to the file must be owned by 
>> either the owner of the file or root and no directories must be group or world 
>> writable."

>> The "Users" directory is owned by "SYSTEM" (numeric: 18 according to stat) and 
>> only writable by Administrators and SYSTEM. The mode cygwin shows for 
>> /cygdrive/c/Users is 0750 which should be OK.

>> So my question is: are "Administrators" and "SYSTEM" different users and does 
>> cygsshd accept SYSTEM (numeric 18) as a valid user who may own system 
>> directories? If the numeric ID is really 18 I can't see how this check can 
>> succeed but I'm not sure the code used in Cygwin is the same.

	$ id SYSTEM
	uid=18(SYSTEM) gid=18(SYSTEM) groups=544(Administrators),18(SYSTEM)

> Administrators and SYSTEM are not the same.  And neither is exactly equivalent
> to the concept of root in POSIX.  SYSTEM (in my experience) is used for things
> like backup tools that needs access to almost every file.  Administrators is for
> system administration.  I don't have deep knowledge of all of this - others can
> give a deeper / more nuanced answer.

Look at permissions at all levels:

$ lsattr -d ~/.ssh/;echo;ls -dl ~/.ssh/;echo;getfacl ~/.ssh/;\
				icacls `cygpath -m ~/.ssh`
------------ /home/BWI/.ssh/

drwx------ 1 $USER None 0 Mar  8  2023 /home/$USER/.ssh/

# file: /home/$USER/.ssh/
# owner: $USER
# group: None
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

.../.ssh/ $HOST\$USER:(F)
           $HOST\None:(Rc,S,RA)
           Everyone:(Rc,S,RA)
           CREATOR OWNER:(OI)(CI)(IO)(F)
           CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA)
           Everyone:(OI)(CI)(IO)(Rc,S,RA)

Successfully processed 1 files; Failed processing 0 files

Try:

# add perm query cmds for info before and after changes
$ chmod -c u+rwx,go-rwx	~/.ssh/
$ setfacl -b		~/.ssh/
$ chmod -c u+rwx,go-rwx	~/.ssh/	# same as before

then ls -l ~/.ssh/ and ensure that:

- non-key ssh files	...		have	u+rw-x,go-rwx 	perms,
- private key files	id_...		have	u+r-wx,go-rwx 	perms, and
- public key files	id_*.pub	have	a+r-wx 		perms.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry