something not setup correctly when using only sshkey based auth

[jtnord]

Hi,

We are having a very strange issue that we do not understand.

We have a Server VM (cloud based) (appiles to 2022 and 2025) in which openssh is installed.
The init scripts add a new local user, run a process as that user (to ensure the profile is created) add the user to "open ssh" users group and give the user an authorized key.

All of this is scripted (no GUI access).

The problem is if we ssh in with the users key the authentication works, however something is not initialized/working correctly as
attempting to access the CryptAcquireContext returns ACCESS_DENIED.

If we then ssh using the username:password instead of the private_key then this API works.

If we then ssh using the private_key then the API is also working.

So something is doing something when we use username/password auth but not ssh key based auth to presumably set something up in the profile (if we login via RDP and then logout instead of using username/password) then the same applies, the CryptAcquireContext starts working from the ssh-key based auth.

I'm at a loss as to why this is not working or how we can work around this issue.

the initialization script is like the following obviously the password is different:

Write-Output "= Installing OpenSSH Server..."
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Write-Output "= Setting up OpenSSH Server..."
Set-Service -Name sshd -StartupType 'Automatic'

Write-Output "= Starting OpenSSH Server..."
Start-Service sshd

Write-Output "= Adding OpenSSH to the Firewall..."
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 | Out-Null

# not the real password!
$pw = ConvertTo-SecureString -String 'something1234SOMETHING@@@' -AsPlainText -Force
Write-Output "= creating test user"
New-LocalUser -Name test2 -Password $pw

Write-Output "= Adding user to OpenSSH group"
Add-LocalGroupMember -Group "openssh users" -Member "test2"

# Ensure user profile is created (doesn't seem to matter if this is run or not!)
Start-Process -FilePath cmd.exe -ArgumentList "/c","echo initialized" -Credential $cred -LoadUserProfile -Wait

# Setup SSH key for user in its profile
$userSSHDir = "C:\Users\test2\.ssh"
New-Item -ItemType Directory -Path $userSSHDir -Force | Out-Null

$authorizedKeysFile = "$userSSHDir\authorized_keys"
$keyUrl = 'https://raw.githubusercontent.com/jenkins-infra/aws/main/ec2_agents_authorized_keys'
Write-Host "Downloading SSH key from $keyUrl to $authorizedKeysFile"
Invoke-WebRequest $keyUrl -OutFile $authorizedKeysFile
# yes the above creates the key as the administrator user not the test2 user - but authentication still works which was surprising...

more attempts t debugging this are recorded in jenkinsci/credentials-plugin#999 but we have seemingly hit a dead end.

[StevenBucher98]

Hey @jtnord Thanks for the issue, it seems like the CryptAcquireContext API is deprecated according to the docs you linked, SSH does not use that API so not sure how much we can help in this scenario...

[jtnord]

it helps in so far as it does confirm there are differences in the shell/session between a key based auth and a username/password auth (so we are not going mad!).

However, we are not using a domain controller (the server is a standalone machine not in a domain) and using COMPUTERNAME\username does not make a difference.

[tgauth]

I can provide a little more context on why the SSH session differs based on the auth type (but I really don't know much about their downstream consequences that seem to result in Windows differences with initializing a user profile).

For password auth, LogonUserExExW() gets called (see https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/win32compat/win32_usertoken_utils.c#L818-L819 / https://learn.microsoft.com/en-us/windows/win32/secauthn/logonuserexexw)

For key-based auth, LSALogonUser() gets called (see https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/win32compat/win32_usertoken_utils.c#L206-L208 / https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsalogonuser)

As for how to workaround the session difference, here's some conjecture from Copilot...

• LogonUserExExW() with LOGON32_LOGON_NETWORK_CLEARTEXT completes cryptographic provider initialization, whereas LSALogonUser() with S4U logon does not.
• The workaround attempt with Start-Process -FilePath cmd.exe -ArgumentList "/c","echo initialized" -Credential $cred -LoadUserProfile -Wait will only load the existing user profile, seemingly like the key-auth'd session does.
• To mimic the same initialization as RDP/SSH with password auth, you could try using psexec, but ultimately some sort of network logon with creds needs to be done to initialize the crypto providers.

[timja]

Would this be a bug in the Win32-OpenSSH project? i.e. I would expect the Crypto API's to work even if the first logon of a principal is key based.

I expect this doesn't happen too often as unless you build a key into an image in most cases the first auth on Windows will be via a password.

[tgauth]

I expect this doesn't happen too often as unless you build a key into an image in most cases the first auth on Windows will be via a password.

agreed - which I think makes this a limitation of the Windows APIs, rather than a bug Win32-OpenSSH would even be able to address.

[jborean93]

SSH key auth doesn't have access to your password to decrypt things like the DPAPI store. It's a limitation based on the authentication mechanism used and sshd cannot do anything to work around this. The only possibility would be to store your password in a reversible fashion on the Windows host which is not a good practice and would be eviscerated by any security researcher.

The crypto APIs would work but in the context where they need to access something that is encrypted by DPAPI or your account's password. Only a logon done where the username and password were supplied would be able to do that. You'll see the same limitations with things like PSRemoting over WinRM unless you use a logon like CredSSP which does send the plaintext username/password to the remote to logon.

[matsmcp]

I do not have an answer to why it doesn't work but I may have another way to do it.

You can configure SSH to accept more than one path to key files.
for example something like
AuthorizedKeysFile __PROGRAMDATA__/sshkeys/%u/authorized_keys .ssh/authorized_keys
Would look for pubkeys in programdata\sshkeys%username%\authorized_keys and .ssh/authorized_keys, You still need to put the ACL:s right but you would now have a more "stable" folder structure

[jtnord]

the key is not the issue - we can ssh with either the key or password and auth is fine. Its just in the resulting shell "some things" fail (like things accessing CryptAcquireContext.

But it only fails until that user either

1. uses ssh with username/password once
2. logs in using RDP (once)

once the user has performed any of the above actions then if you ssh in using the private key the tools that previously failed when using ``CryptAcquireContext` work.

We have no ability to change this API to the non deprecated version as the tool is not under our control (we just created a minimal reproducer)

[timja]

(The tool is Java for their SecureRandom provider on Windows)