Hana

For completeness, the tool people are usually pointed at is sshpass, which feeds a password to the client through a pseudo-terminal. It exists, it works, and it takes the password either as an argument, from a file, or from an environment variable.

It is worth knowing about because you will meet it in other people's scripts. It is not worth choosing, because every form of it leaves the password somewhere readable, and the file and environment variants are only marginally better than the command line.

The cases where it is genuinely the least bad option are narrow: a device that cannot accept keys at all, or a one-off migration. If you find yourself installing it for ongoing use, that is a sign the underlying setup needs fixing rather than working around.

A third route that avoids the whole question if you are on a recent Windows: use the built-in OpenSSH client instead.

Windows has shipped an OpenSSH client for some years now, usable from the command prompt or terminal exactly as on Linux. It reads OpenSSH-format keys directly, so no conversion is involved and neither format problem arises.

That does not help if you specifically need the graphical client or the tools built around it, and for anyone whose only reason for using it was that it was the way to get ssh on Windows, the reason has expired.

The mechanism is a module in the authentication stack that counts consecutive failures per user and refuses further attempts for a configured period. It is not the account being disabled — the account is fine, there is simply a counter above the threshold.

Since you have root, clearing it is one command. The tool that manages the counter can show you the recorded failures for a user and reset them:

faillock --user yourname          # show the recorded failures
faillock --user yourname --reset  # clear them

Run that as root and the account is immediately usable again. No reboot, no waiting.

On systems using the older module the equivalent tool is pam_tally2, with the same idea — a listing option and a reset option. Which one you have depends on the distribution's vintage, and trying both costs nothing.

The other honest option, if the distribution has just been installed and contains nothing you care about: delete it and install a current image.

Unregistering a distribution and installing it again takes a couple of minutes, and if the underlying problem is that the snapshot is old, a current one avoids the whole exercise.

Worth doing that before spending an hour on a machine you set up ten minutes ago.

The format of the username trips up nearly everyone attempting this, and it is worth stating explicitly.

For an online account, the username for remote desktop is generally the full account address, not the display name and not the local profile folder name. Many people try the name they see on the sign-in screen, which is a display name and is not an account identifier at all.

Another frequent cause: the account must be permitted to connect. Being an administrator is usually enough, but on some configurations the account has to be added explicitly to the list of users allowed remote access.

And if the account has multi-factor authentication enabled, that adds a further complication, because the remote desktop prompt has nowhere to present a second factor. Configurations exist that handle it, and it is the thing to check before assuming the password is wrong.