Wanda

One detail that catches people setting this up for scripts: if you gave the key a passphrase, you will still be prompted — for the passphrase rather than the password.

That is usually what you want interactively, and you handle it with an agent that holds the key unlocked for your session. For an unattended script running with no human present, you need either a key with no passphrase, restricted to exactly what it needs, or an agent already running with the key loaded.

If you use a passphraseless key, restrict it. On the server, the authorised keys file lets you pin a key to a single command, to specific source addresses, and to disable port forwarding and terminal allocation. A key that can only run one script from one address is a very different risk from one that grants a shell.

That pairing — passphraseless key, tightly restricted — is the standard way to automate this properly.

There is a direct way and you do not need the file. From the Windows side you can run a command inside the distribution and capture its output, which means any command that reports the address works:

wsl hostname -I

That starts the default distribution if it is not running and returns its address. It takes a few seconds on a cold start and is instant afterwards.

If your distribution has several interfaces, hostname -I returns all of them and is ambiguous. In that case be specific:

wsl ip -4 addr show eth0 | wsl grep -oP '(?<=inet\s)\d+(\.\d+){3}'

or simply run the whole pipeline inside the distribution with a single wsl bash -c '...', which is easier to get right than mixing the two shells.

The other fix, and usually the better one: update the client.

The format changed because the newer version has real improvements in how the key is protected at rest. Downgrading the file to satisfy an old client works and it gives up those improvements.

If the thing reading the key is a tool you cannot update — a build server, an appliance, an old deployment script — then downgrading the file is the pragmatic answer and it is fine. If it is simply an old copy of the client on your own machine, update it and the problem disappears permanently rather than needing to be handled again on the next key.

Worth checking every tool that will read the key before deciding, because it is easy to fix the client and then discover the file transfer program has the same complaint.

Two further causes that produce the same code once the obvious ones are ruled out.

Exploit protection settings. Some security configurations disable a control flow protection for the virtual machine compute service, and that stops the machine starting. It is a per-program setting and it is easy to check and re-enable in the exploit protection panel under program settings.

Another hypervisor holding the hardware. Some third-party virtualisation software takes exclusive control of the virtualisation extensions, which prevents the platform from starting its own machine. Older versions of the popular desktop virtualisation products did this; recent ones generally coexist. If you have one installed, updating it or shutting it down is worth testing.

Corporate machines add a third possibility: security policy that disables the features entirely, in which case no local change will help and it needs to go through whoever manages the device.

One thing that confuses people here: the lockout is usually per account, not per source.

So somebody else failing to log in as your username from elsewhere locks you out at the console. That is by design — the alternative would let an attacker keep trying from new addresses — and it means a lockout is not always evidence that you mistyped anything.

Worth understanding why this happens specifically to subsystem installations, because it tells you how to avoid it.

Distribution images made available through the subsystem are snapshots, and they can be considerably older than the current release. Signing keys are rotated periodically, and an image built before a rotation ships with keys that have since been replaced. Everything worked the day it was published and breaks for everyone who installs it afterwards.

So the recurring fix is: install the image, then immediately update the keyring before anything else.

It is also an argument for getting images from the distribution's own current source rather than an older packaged one, where that is an option. A current image does not have the problem at all.

One more thing worth checking before you change any settings: whether the edition of Windows on that machine supports hosting remote desktop at all.

The consumer edition can connect out but cannot accept incoming sessions. If the fresh install ended up on that edition, no amount of credential work will help, and every guide you find will appear to be describing a different machine.

It is a five second check and it explains a surprising share of hours lost to this problem.