Serkan

There is deliberately no such flag, and understanding why points straight at the right answer.

A password on a command line ends up in your shell history, in the process list where any user on the machine can read it, and often in logs. Every one of those is a place a credential should never be. The client refuses to accept one for that reason, not as an oversight.

The correct solution is public key authentication, which is easier than the workaround and better in every respect:

1. ssh-keygen -t ed25519 to create a key pair if you do not have one. Accept the defaults.
2. ssh-copy-id user@host to install the public half on the server. This asks for the password once, and only once.
3. ssh user@host now connects with no prompt.

That is the whole procedure and it usually needs no server configuration at all. For a script, this is the answer — non-interactive, no secret on any command line, and revocable by deleting one line on the server.

Worth knowing that the networking model here has changed across versions, and advice you find online may describe a different arrangement than the one you have.

The original design gives the subsystem its own virtual network with an address that changes on each restart, which is the situation you describe. Newer configurations offer a mode where the subsystem shares the host's network directly, and in that mode the whole question disappears — services are reachable as if they were running on Windows.

If you are fighting the address problem regularly, checking whether your version supports that mode is a better investment than automating around it. It is a configuration setting rather than a reinstall.

There are two separate format questions tangled together here and separating them makes it simple.

Format one: OpenSSH versus PuTTY. The client uses its own private key format rather than the OpenSSH one. That is why your original key is rejected, and converting it with the key generator is the correct step.

Format two: which version of the PuTTY format. The key file format itself has been revised, and a newer generator produces a newer version. An older client — or another tool that reads these files, such as some file transfer clients and deployment tools — only understands the older one. That is the "too new" message: the file is valid and the reader is older than the format.

The fix is to save the key in the older version. In the key generator there is a parameter setting for the file format version; set it to the earlier version, load your key and save the private key again. You now have a file the older client accepts.

Worth noting that the error codes in this area are not very informative by design — they surface from a lower layer and mean "the machine did not start" rather than why.

The more useful diagnostic is the Windows event log, under the virtualisation-related sources. It frequently contains a specific reason where the command line gave you a number, and it is where I go first now rather than working through the checklist blind.

Worth looking at the listing output before resetting rather than clearing it reflexively.

The record shows when each failure happened and from where. If the failures are all from your console in the last two minutes, that is you mistyping and there is nothing to think about.

If there are failures from times you were not at the machine, or from a network source, that is a different situation and the lockout just did its job. On a machine reachable from the internet, repeated failed attempts against a named account are routine background noise, and seeing them is a good prompt to check that password authentication is disabled for remote access in favour of keys.

So: read, then reset.

The alternative that sidesteps all of this: create a local account on the machine specifically for remote access.

A local administrator account with an ordinary password authenticates against the machine directly, with no online account, no PIN and no second factor in the path. Connect to it by machine name and account name.

This is what I do on any machine I need to reach remotely, precisely because it keeps remote access independent of whatever the online account is doing. It also means that if the online account has a problem — expired password, changed policy, a device-trust issue — remote access still works.

The trade is another account with administrative rights, so give it a strong unique password and do not use it for anything else.