Inherent "User Key Permissions Update Approach" May Cause Lockouts? (Possible Solution OpenSSHUtils.psm1 Should Expose Fix-FilePermissions Function)

[DarwinJS]

Thanks for Using Pure PowerShell!

First of all a huge thanks for using pure powershell for your permissions solution - that's awesome!

It Is Not Realistic To Require Each User To Reset Their Own SSH File Permissions

I am attempting to create a comprehensive fix up utility Reset-SSHFilePermissions that will handle all user permissions when run from admin context.

It uses the profile folder list from "ProfileList" registry key to avoid bad profiles and profile folders that have been created manually and to catch profile folders of all special system accounts.

I was excited to see that the permissions functions in OpenSSHUtils.psm1 could likely be directly leveraged.

However, the script solutions provided continue to take on the perspective of "running in the context of the user who needs fixing to do that actual fixing" This is not really a scalable way to fix up a server with many, many ssh logins.

Complex Automation Logistics for Automating for "Every User"

I previously commented on the idea that permissions fixup scripts should NOT assume they will be run from each user's context here: #721 (comment)

Envision a scenario where you have 100 ssh users using 50 servers with OpenSSH and the server upgrade is necessarily spread over some time (normal software deployment automation lag time, or lag times in manual upgrades).

SSH login does not trigger many of the typical windows methods of scheduling "next login" type operations. Even if it does support some, the trickyness of setting up "run only once" processes causes many admins to just set things to run every time for everyone, forever (because they dont' know when a given user will logon to a given machine).

Additionally, if an admin were to set up automation on per-user basis - when they start upgrading some of their servers, it will be a likely scenario for the user portion to run on a given server before that server has been upgraded to 0.0.15.0. I'm not sure, but it seems like resetting the permissions to v0.0.15.0 standards on a server that has binaries that are older than 0.0.15.0 might cause issues?

It almost seems like the vision for running this code is that each user manually runs the script on each server they logon to.

Chicken and Egg Scenario?

Also - if I run the v 0.0.15.0 upgrade on a server and SSH users generally only access the server using SSH - won't they be denied logon until they fix permissions - therefore requiring that they logon to that windows machine by another means to run the fixup script for themselves? Some of these machines may have ports for other access methods restricted - effectly locking them out?

Handle All User Permissions During Binaries Upgrade

I think it is much more appropriate to handle individual user fixups as part of the machine level install / upgrade of OpenSSH because it will:

1. be timed exactly when the binaries are upgraded on a given server (an implicit synchronization requirement created by the linkage of release 0.0.15.0 requiring specific permissions to operate correctly),
2. handle all valid profiles on the same machine,
3. ensure the user key permissions are only done on the servers that have been upgraded to 0.0.15.0 or later. (possible github issue source.)
4. ensure that no user key files are missed on an upgraded server. (Likely github issue flood from this one.)

[FYI I tend to use the risk of github issue floods is a litmus test of when my envisioned use of software will not match the real world needs.]

Possible Easy Solution

The function Fix-FilePermissions takes a user as an argument - so the fundamental requirement of setting user permissions for a user other than the current seem to be in the cocde - but this function does not appear in Export-ModuleMember in the .psm1.

The exported function Fix-UserKeyPermissions that calls Fix-FilePermissions does not expose a username, but is hardcoded to the current user.

Could you please export this function as a module member so that I can access the underlying function to set proper user permissions on users other than the current user?

[manojampalam]

Thanks @DarwinJS for thinking through upgrade scenarios.

Regarding fixing up of individual file permissions, I assume you are referring to ssh_config and user's key files. If so, these are strictly client side (host would have no impact).
The only user specific file that applies on host side is authorized_keys - this is taken care of in FixHostFilePermissions.ps1

Lockout is a serious concern, I've added a warning to release notes for now. I understand that your Chocolatey package covers upgrade scenarios, we can work out a solution to prevent this issue - an explicit call to FixHostFilePermissions.ps1 along your upgrade path can help. Let us know how we help validate possible solutions and investigate related issues. We'll prioritize accordingly.

[DarwinJS]

@manojampalam - apologies I missed the enumeration of profiles in FixHostFilePermissions.ps1 - I will call this script. Thanks for providing a non-per-user approach!

[bingbing8]

@DarwinJS Fix-UserKeyPermissions now takes -User parameter and also Fix-FilePermissions is exposed. Please check.

[DarwinJS]

@bingbing8 - while I haven't tested the resultant install for lockout - the chocolatey package is calling FixHostFilePermissions.ps1 to fix the permissions. I will close this as already being addressed by the tools provided with Openssh.