Wiktor

Worth adding the piece that makes key authentication genuinely pleasant rather than merely correct: the client's config file.

A block in ~/.ssh/config giving a host an alias, a user, a port and a key means your script says ssh myserver and nothing else. No flags, no paths, no repetition, and changing the server means editing one file rather than every script.

Most people discover this years after they start using ssh and immediately wish they had not.

If you do end up scripting it, one detail that will bite: output from a command run through the subsystem often arrives with a trailing newline and sometimes with different line endings than the Windows shell expects.

Trim it explicitly before using it in a connection string. Half the reports of "the address is correct but the connection fails" come down to an invisible character on the end.

One practical note on the conversion, since people frequently lose a key here: the generator can convert in both directions.

Load a PuTTY-format key and there is an export option that writes an OpenSSH-format file. So if you converted your only copy into the wrong format, nothing is lost.

Worth keeping both formats of any key you use across mixed environments, in the same secure place. It takes a minute and saves this exact hour.

A practical note on the enabling step: doing it through the graphical features dialogue and doing it from an elevated command line are equivalent, and the command line version is easier to verify and to repeat on another machine.

Whatever route you take, enable both features in one go and reboot once. Enabling one, rebooting, testing, then enabling the other is how people end up convinced that the first change did nothing.

After the reboot, verify before installing anything: the version command should report the subsystem version rather than an error. If it does not, the distribution install will fail again and the code will tell you no more than it did the first time.

For the configuration side, since you will meet this again: the settings live in the authentication configuration, and the two numbers that matter are the failure threshold and the lockout duration.

Worth knowing that different distributions place these in different files and that some have a specific configuration file for the module. Editing authentication configuration is one of the easier ways to lock yourself out of a machine entirely, so the standard precaution applies: keep a root shell open in another terminal while you change anything, and test logging in from a third one before you close either.

That habit has saved me more than once, and the one time I skipped it cost me a trip to a data centre.

One trap worth flagging: advice for this problem circulates with specific file names and URLs, and those go stale.

Keyring package names and locations change over time, so a command copied from a two-year-old answer frequently returns a not-found error — which people then interpret as a further problem rather than as an outdated instruction.

The durable approach is to look up the current keyring package on the distribution's own site and use today's name, rather than copying a command. Slower by two minutes and it works on the first attempt.

The key thing to understand is that the PIN is not a password. It is a local credential tied to that specific device and its secure hardware, and it unlocks a key stored there. It has no meaning to anything else and cannot be sent over a network, which is exactly why it is more secure than a password for local sign-in.

Remote desktop authenticates with an account and password. So you need the password of the online account, not the PIN.

The usual reason that fails is the second half: on a fresh install configured this way, signing in with a password is often effectively disabled locally, and the account may never have had a usable password established on that device.

The supported route is to re-enable password sign-in for the account and confirm the online account's password works locally, at which point remote desktop accepts the same credential.

The other factor is that unfamiliar movement produces disproportionate soreness the first several times, and then stops.

This is well described: the first exposures to a new pattern, particularly one with a lot of lengthening under load, produce far more muscle soreness than the same work does once you have adapted. The effect is large and it fades quickly with repeated exposure.

So the expected trajectory is that this improves substantially over the next month or two, and it will improve faster if you surf more often rather than harder. Two shorter sessions a week will build tolerance more quickly than one long one, because the adaptation is driven by exposure.

If it is not improving at all after two or three months of regular surfing, that is worth looking into — but at one month, this is the normal course.