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

[phr34k]

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.

[jborean93]

There is no solution to this, if you authenticate to the server without providing the password for the user then you cannot unlock the DPAPI store for that user and access it's secrets. Any workarounds would require the password to be stored in a reversible fashion that the system could use or to provide enough information to be able to delegate the credentials to the remote host during the authentication phase.

Delegation is a tricky problem to solve, the best thing to do would be to structure your workflow to not require it at all. That's easier said than done but still possible. For example you could use sftp to copy files to the host before running commands, download from a web location rather than a filesystem, set up resource based delegation, use kerberos + delegation. Delegation opens yourself up to more potential problems going forward but that's the trouble you get when you need to delegate authentication info.

[phr34k]

@jborean93 I am aware and I'm also trying to adjust myself. That being said, there's a limit to what are reasonable ask(s). If you are in full control and can provide adequate alternatives, then yes maybe it is reasonable. However that's not always the case e.g. third-party applications don't always have straightforward alternatives.

Compromising on security though workarounds- is still a compromise and a risk. For example temporally uploaded scripts with sensitive passwords can be left on the file system by accident due to broken connections in flight, forgetfulness. It's something that I would classify as security risk, and wouldn't like to see encouraged as a "solution".

This is a technical problem, that can also have a technical solution. In terms of delegation maybe the initiating ssh terminal can run some kind of ssh-agent counterpart to requests this passwords from or the computer has some kind of vault that allows authorizes public keys to reverse the password.

I think at least it requires more attention and an open dialog with @MSFT for possible solutions.

[jborean93]

Sure you can ask but trying to tunnel credentials or storing them in some reversible fashion is just as risky as sending the credentials in your command. PSRemoting ssh connections offer a way to send a “SecureString” to the remote session and avoid it getting logged by anything inadvertently but even then it’s still a risk.

The crux of the issue is that you wish to make someone’s ssh key the same as their password or at least to prove their identity across multiple hosts which requires some central identity. At this point we are essentially talking about an auth protocol like Kerberos which is already achievable today. Even then there are risks involved with this delegation.

This is just my 2 cents and not affiliated with MS. They may weigh into the conversation but based on historical issues I would not be surprised if it’s just the same response.

[nhatkhai]

If the sshd services run under a valid domain/a normal local account difference than the default "Local Account" - the cmdkey will work just fine.