Possibility of having a Disable File Ownership flag

[CEbbinghaus]

I haven't found any better place to post this so I'm going to open this issue to at least get some clarity.

I have been fighting against my operating system to let me change the permissions of the config file but it seems that it's impossible (at least trying to do what I am). My issue/question however is why there isn't a --disable-security-checks flag to skip the checking of the key/config permissions. Since it's such an old project I'm sure that I'm not the first that has wondered this but I can't find anywhere that says why it's not going to be added.

The flag could trigger a !! WARNING !! that gets printed every time it gets used to warn the user. But outright disabling the option to even use ssh if the files aren't secured properly makes it impossible for anyone that doesn't have the ability to change the file permissions.

I'm more wondering what the design ethos is and why this hasn't been added or at least discussed? (I have found a few posts talking about it but so far its has been just saying "No you can't")

If this is not the place to ask this question it would be nice to know where design discussions for this project take place.

Cheers

[panekj]

If this is not the place to ask this question it would be nice to know where design discussions for this project take place.

This isn't the original source for OpenSSH, you should ask in https://github.com/openssh/openssh-portable or better yet check https://openssh.com

afaik, check has been introduced in ~~https://github.com/openssh/openssh-portable/commit/eba71bab9bf01c0d688f829a8971f902732558df~~ https://github.com/openssh/openssh-portable/blame/4d2f15f895f4c795afc008aeff3fd2ceffbc44f4/authfile.c#L228-L238 from OpenBSD OpenSSH

[CEbbinghaus]

@panekj tank you for the response. I was going to post it in the original OpenSSH repository but since my issue is windows exclusive it's hard to justify the reasoning for Linux. Makes sense though and thank you for the link to the commit

[mgkuhn]

The "design ethos" comes from the OpenSSH project, which is run by the OpenBSD folks (Theo de Raadt, et al.), and they are renown for being somewhat uncompromising when it comes to security. OpenSSH has a long history of being picky about the file-access permissions of its configuration files, to prevent vulnerabilities due to permission accidents on multi-user systems. The main difference between Unix and Windows is here that the rwxrwxrwx permissions on Unix are quite simple, easy to understand, review and fix (e.g. chmod go-rw), whereas the NTFS ACLs are quite complex, and are typically fully understood by only a tiny fraction of Windows users.

In case it helps: the best introduction to Windows ACLs that I've read is section 2 of this excellent SACMAT 2001 paper by Swift et al., because it gives you the actual algorithms used. (I never found anything as clear in Microsoft's documentation. Also, the on-board tools, such as icacls or File Explorer, are hardly self-explanatory and require significant expertise.)

[CEbbinghaus]

@mgkuhn thank you for that link. As much as I agree that security comes first it is first and foremost a tool, and the simple fact that in certain circumstances it's completely impossible to use makes it less versatile/usable as it would otherwise be. One of the reasons I decided to create this Issue on the windows version is because it solely exists because windows file permissions are weird and this gets further complicated when you have files shared between Windows and WSL Linux. What works for windows doesn't work for Linux (unless you configure it to preserve metadata and even that isn't foolproof) and it doesn't work at all vice versa. This makes it hard for example to share a single configuration between the host and guest operating system allowing the user to connect to a remote machine both via windows and wsl.

[mgkuhn]

Reading man sshd I see under ~/.ssh/authorized_keys:

If this file, the ~/.ssh directory, or the user's home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to “no”.

And under man sshd_config:

StrictModes – Specifies whether sshd(8) 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''.

Does StrictModes no not already solve your problem?

If no:

Could you provide a specific reproducible example of the configuration that causes you trouble? Which file (full pathname please)? What kind of filesystem is it stored on? What are its NTFS permissions as shown by iacls? What are its POSIX permissions as shown by ls -la? Please also include the permissions of the parent folders up to %USERPROFILE% or $HOME in both cases.