How Windows OpenSSH Broke My Brain

There are errors you can fix with a two-second Google search, and then there are those that drain your time. A prime example is an SSH connection failure to a Windows Server, where the OpenSSH service drops the following logs into the Event Viewer:

sshd: error: get_user_token - unable to generate token on 2nd attempt for user administrator
sshd: fatal: ga_init, unable to resolve user administrator

These messages indicate that the Windows authentication subsystem either cannot recognize the user at the OS level or is unable to generate a security token for them. Everything seems properly configured, yet the server persistently drops the connection.

Where the Time Goes (False Trails)

If you start googling this error, 90% of the online advice will lead you down two main paths:

1. Key File Permissions: You will be told to configure ACLs via icacls for the administrators_authorized_keys file located in C:\ProgramData\ssh, disable inheritance, and restrict access exclusively to SYSTEM and Administrators.
2. The sshd_config File: You will be advised to comment out the Match Group administrators block at the very bottom of the config to force OpenSSH to read keys from the standard user profile (.ssh/authorized_keys).

I tried everything on that list. Permissions and configs were verified, services were restarted—yet the result was zero. The server stubbornly terminated the session immediately after successfully validating the key.

The Unobvious Answer

The root cause turned out to be trivial, yet hidden behind the specifics of how OpenSSH operates on Windows.
How does SSH work in Linux? If the key matches, you are in.
How does SSH work in Windows? Even if the key matches, the OpenSSH service (running under the SYSTEM account) needs to establish a fully functional Windows workspace session and generate a user security token using the system API (LsaLogonUser).
And that is exactly where Windows denies the request.
I ran a quick check in the server console:

net user Administrator

And there it was: Account Active: Locked.
As it turned out, the Administrator account was locked out! This was likely caused by routine brute-force attempts—bots kept hammering port 22, triggering the Windows password lockout policy, which “froze” the account. Meanwhile, the SSH server successfully verified and confirmed the key (since the file exists on the disk), but the Windows OS refused to generate a token for a locked user. Hence the completely cryptic log about being unable to generate token.

The 5-Second Fix

If you have run into the same issue, the solution is straightforward. Log into the server using another admin account (or log in locally) and unlock the Administrator.

Via PowerShell:

Unlock-LocalUser -Name "Administrator"

Via the good old CMD:

net user Administrator /active:yes

Immediately after, the connection issues disappear, and the client successfully gains SSH access to the server.