Updating OpenSSH restarts/reconfigures AuthenticationAgent service

[jonaskuske]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

Stop and disable the OpenSSH Authentication Agent in services.msc. Update OpenSSH, in my case via winget.

Expected behavior

Service remains stopped and disabled.

Actual behavior

Service is running and startup type is "Automatic" (instead of "Disabled")

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.4
PSEdition                      Core
GitCommitId                    7.3.4
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

9.2.2.0

Visuals

No response

[tgauth]

I think we can solve this by bypassing the component that sets up the service during upgrades.

@heaths hoping to get your input on this - would the best approach be something like: https://github.com/PowerShell/PowerShell/blob/master/assets/wix/Product.wxs#L118

[heaths]

You can't put a condition anywhere. Service installation has limited control, and Windows Installer does not simply allow using whatever state a resource is in. It is, effectively, a machine state configurator: it puts the machine into the state you declare. It does this for files (though it can take file versions into account), registry values, etc. It's unfortunate it doesn't allow retaining the start type, but that's basically what it was designed to do.

See

• https://learn.microsoft.com/en-us/windows/win32/msi/serviceinstall-table
• https://wixtoolset.org/docs/v3/xsd/wix/serviceinstall/

To solve this would require a number of complex custom actions to detect and persist the current start type, then apply that in install, uninstall, and upgrade, and multiplied by rollback scenarios. Without custom actions, there is a total hack that may not work in all scenarios to have a single file in the MSI package but separate, mutually exclusive components; however, getting those components' exclusivity is not straight forward, and may only work with internally-built (read: old) WiX 3.x builds: it was used - but abandoned - by both .NET and Visual Studio many, many years ago.

We may want to discuss priority and planning with @SteveL-MSFT.

[jonaskuske]

Maybe for context as to why this matters to me:

I'm using the SSH Agent provided by 1Password, and every now and then SSH and everything that relies on it is just not working anymore. After some time I realize that OpenSSH was part of the latest winget upgrade --all, which re-enabled the agent, so I now have to go into services.msc, stop the OpenSSH Agent and set its startup type to deactivated, then restart the 1Password SSH Agent to get my setup working again.

[heaths]

Could you simply remove the daemon if you're not going to use it and keep the client?

msiexec /i {path to msi} REMOVE=Server

This won't install the service so it will never be a problem going forward.

[dinhngtu]

Removing just the server doesn't work since the SSH agent service is part of the shared components. Could the services be split into separate configurable features instead?

[heaths]

Yes, that is technically possible. Either service could be moved to separate features or, if the agent service is required, can be left under SERVER. Some new feature e.g., AUTHSERVER, could be defined as a child of SERVER which will follow it's parent install state by default (or not, but would assume we should). Could then be turned off explicitly.

That's going to be the most straightforward solution. @SteveL-MSFT any objections?

[tgauth]

Can the new feature with the ssh-agent service be a child of both the CLIENT and the SERVER? The option to setup the ssh-agent service should be given if either component is being installed.

[heaths]

Thank you for incidentally reminding me: the ssh_agent.exe is already a shared component of both CLIENT and SERVER, so my original recommendation stands: just remove the SERVER feature per the previous command line. Shared components remain installed as long as one of their features (or are otherwise ref-counted from another installed product) is installed.

[tgauth]

my original recommendation stands: just remove the SERVER feature per the previous command line

I think that would work if this issue was about the sshd service, but it's about the ssh-agent service

An aside, but the sshd service is subject to this issue as well, so if there is a solution implemented, it should probably be done for both services.

[heaths]

In that case, the agent should probably be it's own feature. It can install by default, but could be removed or not installed initially. We should talk with @SteveL-MSFT. I've been consulting with him, and did so initially on this design - mostly following what the scripts did initially, which weren't friendly to package manager. I think separate features, say CLIENT, SERVER, and AGENT is probably safe (they'd have to be siblings, though) but we should brainstorm scenarios to make sure there's no issues.

Alternatively, custom actions (CAs) could be used but are going to be much more expensive. If people don't want the agent, it's better to just not install it. Cleaner.