stored credentionals (e.g. cmdkey) with public key authentication doesn't work.

Troubleshooting steps

I am testing public key authentication to administrator a small group of machines that are not domain joined. Presently sshd doesn't seem play nice with the operating system. When a non-password based authentication method is used subsequently the resulting login shell has no means of interacting with credential manager to use and store saved credentials.

To my knowledge, the following tickets have all been opened and closed dating as far back as 2016. None offering any insights of a permanent solution or discussing what needs to be done to solve this.

https://github.com/PowerShell/Win32-OpenSSH/issues/139
https://github.com/PowerShell/Win32-OpenSSH/issues/1295
https://github.com/PowerShell/Win32-OpenSSH/issues/452
https://github.com/PowerShell/Win32-OpenSSH/issues/996

Password-less login authentication such as public key authentication or signed certificate authentication are often used with remote deployment systems to provide a non-iterative login. Often it's also advised is also to disallow password based login entirely to mitigate risks of "password guessing". The present day working of sshd consequently has some severe drawbacks. With the offered solutions you'd either have explicitly:

• provide credentials for every command, which can be considered a security risk by itself.
• force to use password based authentication method
• reconfigure the service to run as the account you want to login. All of these methods have drawbacks of their own.

The drawbacks of this:

• Utility or maintenance scripts would have to be store their passwords plain text together with the issuing command, which can be risk of anybody who has read permissions to read/execute the file.
• Cannot use a single cmdkey /store to preventing duplication of information, and malicious actors: The passwords passed over command line arguments which can be read in task manager, and malicious actors with the same privileges, and repeating the passwords for multiple commands give more attack surface.
• In case where you run an non-interactive shell e.g. ssh somewhere -c ./dosomething.ps1 you'd have no interactive prompt so an interactive prompting so dynamically prompting for passwords isn't option, even if it was it's a hindrance.
• Sometimes you may actually want to have multiple accounts that have different permissions to accomplish different stuff so re-configuring the service isn't really a viable solution.

I'd argue with a certificate based authentication that the whole point is to not offer persistent authentication method so it's easier to temporarily grant access and revoke to limit access to systems to mitigate security risks. Compromising on security by having to give out a persistent credentials to make cmdkey work is orthogonal to this; hard coding utility scripts with necessary credentials in my eyes seem orthogonal to security principles also.

Is there any proposed fix to make public key authentication and by extension certificate based authentication work properly? I understand that the problem seems rooted in /not/ having the password that credential manager needs to decrypt. Surely there could be some technical solutions to this, like an sshd specific vault to offer an suggestion.

"OpenSSH for Windows" version
((Get-Item (Get-Command sshd).Source).VersionInfo.FileVersion)

Server OperatingSystem
Windows

Client OperatingSystem
Windows

What is failing

Machines that are administrated remotely with public key authentication:

• cmdkey cannot be used to store/edit credentials that are respectively part of the account
• any commands that interact with saved credentials will fail

Expected output

• cmd key being able to save/edit credentials
• subsequently being able to use commands like net use which use previously stored credentials

Actual output

CMDKEY: Credentials cannot be saved from this logon session.

Start by reproducing a public-key login on Windows, then run cmdkey /store and compare the resulting session with password authentication. Trace the sshd logon-session behavior and its interaction with Credential Manager, using the four linked historical issues for context. Done means the required credential operations work in a public-key-authenticated session without weakening the stated authentication model.