Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
If SSH asks for the remote account password after you configured a key, the public-key authentication attempt either failed or the server deliberately requires another method. A prompt for your private key’s passphrase is different: it unlocks the encrypted key on your own computer and can be normal.
Run ssh -vvv to identify which key SSH offers, then verify the username, host, server-side key file, permissions, and effective sshd policy. On Windows, also check the administrator-specific key path and ACLs.
First, identify which password SSH wants
Two prompts can look similar but occur at different stages and require different fixes. Do not change the server configuration until you know which one you are seeing.
| Prompt | Where it is handled | What it means | Normal action |
|---|---|---|---|
| Private-key passphrase | Your SSH client | The private key is encrypted and must be unlocked before the client can use it. | Enter the passphrase, or load the key into an agent so it can be reused during the session. |
| Remote account password | The SSH server | The public-key attempt did not complete, or server policy has moved to password or keyboard-interactive authentication. | Diagnose key selection, account/key placement, permissions, and authentication policy. |
A passphrase belongs to the key file on your computer. It is not the password for the Linux, Unix, or Windows account you are connecting to. The server compares the public key associated with the account to proof produced with the matching private key; it never needs your private key file.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Use verbose SSH output to locate the failure
Start with the exact connection you normally use, adding maximum client-side diagnostics and explicitly selecting the private key:
ssh -vvv -i ~/.ssh/id_ed25519 user@example.comReplace the username, host, and key path with your values. Ubuntu’s SSH guidance recommends -v or -vv when public-key authentication fails; -vvv exposes more detail when the first two levels are inconclusive.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsWhat to check in the debug stream
- Remote username: Confirm the command contains the account whose home directory holds the key.
admin@example.comandroot@example.comare different accounts even on the same host. - Hostname and address: Make sure DNS, an alias, or a bastion is not sending you to a different server than the one where you installed the key.
- Identity files considered: Look for the private-key filenames SSH searches automatically. A key saved under a nonstandard name may never be offered.
- Key offer and acceptance: The log should show the intended public key being offered. If the server rejects it and the client proceeds to password or keyboard-interactive authentication, investigate the server-side path and policy.
- Private-key loading errors: Messages about an unreadable file, an invalid format, or a failed passphrase indicate a local key problem rather than an incorrect
authorized_keysentry.
Use an SSH configuration entry for a nonstandard key
If the key is not one of the default filenames, either keep using -i or define it in your client configuration:
Host my-server
HostName example.com
User user
IdentityFile ~/.ssh/work_keyThen test with ssh -vvv my-server. The alias does not change the server account; it only makes the intended host, username, and identity explicit.
Confirm that the public key belongs to the target account
OpenSSH reads public keys for a user from the file named by the effective AuthorizedKeysFile setting. The documented default is .ssh/authorized_keys and .ssh/authorized_keys2, resolved relative to that user’s home directory. A server can override this with an absolute path, another relative path, or a dynamic AuthorizedKeysCommand.
Common placement mistakes
- The key was copied to another user’s home directory, but the SSH command names a different user.
- The key was installed on a staging or old server while the command reaches a new address.
- The account’s home directory is not the directory you assumed, so a relative
.ssh/authorized_keyspath resolves elsewhere. - An included configuration file or a
Matchblock changesAuthorizedKeysFilefor this account or group. - The server obtains keys dynamically through
AuthorizedKeysCommand, so editing a local file has no effect.
Copy only the public key line to the server. The line normally begins with a key type, contains a long base64 value, and may end with a comment. Never copy the private key to the server or paste it into authorized_keys.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Check the key pair on the client
When several keys exist, make sure the public key you installed was derived from the private key you are actually offering. A changed filename, regenerated key, or stale backup can leave two unrelated pairs that look similar in a directory listing. Specify the intended private key with -i while testing, then compare the corresponding public-key line with the line installed for the remote account.
Rank #2
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
Check ownership and permissions on the server
OpenSSH can ignore a key even when its text is correct if the path is considered unsafe. Ubuntu specifically identifies overly open permissions on the home directory, .ssh, or authorized_keys as a common cause of public-key failure.
Inspect every directory in the path
Using the target account, inspect the home directory, the .ssh directory, and the key file. On Unix-like systems, commands such as ls -ld and namei -l reveal ownership and mode bits for each path component. Check that:
- The home directory is owned by the intended account or by the platform’s approved administrator.
.sshis in that account’s actual home directory and is not writable by unrelated users.authorized_keysis owned and readable according to the operating system’s OpenSSH guidance, without broad write access.- Every parent directory permits the SSH daemon to traverse the path but does not allow an untrusted user to replace a directory or file.
Use the restrictive ownership and modes documented for your distribution and account model. Do not blindly apply a numeric mode copied from another system: centralized identity, shared homes, SELinux or other mandatory controls, and administrator-managed accounts can change what is appropriate. After correcting the path, rerun the same ssh -vvv test.
Free tools Windows power users keep installed
One-click scans. No signup required.
Agent state can hide the intended key
If you expect an agent to supply the key, inspect its identities before changing server files:
ssh-add -lIf the intended key is absent, load it for the current account with ssh-add /path/to/private_key, then retry. An agent with many identities can also cause the client to offer keys other than the one you installed; explicit -i testing removes that ambiguity.
Inspect the server’s effective authentication policy
The configuration file you opened may not be the policy SSH is actually using. OpenSSH can include other files and apply account- or group-specific Match blocks. If you administer the server, review the complete effective configuration for the connection’s user and source address.
Settings that determine key login
PubkeyAuthenticationmust permit public-key authentication.AuthorizedKeysFilemust resolve to the location where the public key is installed, unless a configuredAuthorizedKeysCommandsupplies it.AuthenticationMethodsmay require additional methods after a successful key.- Password or keyboard-interactive settings determine whether a fallback prompt is available when the key is rejected or when a second factor is required.
The available authentication methods include publickey, password, and keyboard-interactive, among others. A password prompt therefore does not by itself prove that the key was never attempted.
Rank #3
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
Validate before restarting
When changing sshd configuration, validate the syntax with the platform’s documented configuration-test procedure before restarting the daemon. Keep an existing session open and test a new session in a second terminal. Do not disable password fallback until key login has succeeded independently; otherwise a typo in the key path or policy can lock you out.
Understand when the password prompt is intentional
AuthenticationMethods can require a sequence such as publickey,password. In that configuration, the server first requires a valid key and then asks for the account password. OpenSSH documents that every method in at least one configured list must be completed, in order, and each method must also be enabled.
| Observed behavior | Likely interpretation | Decision |
|---|---|---|
| Key is offered and accepted; password follows every time. | A multi-step policy such as publickey,password is active. |
Keep the prompt if the policy is intentional; otherwise review AuthenticationMethods and applicable Match rules. |
| Key is offered, rejected, then password appears. | Key lookup, account identity, permissions, or key pairing failed and password fallback is enabled. | Fix the failed key layer before changing fallback settings. |
| No intended key is offered. | The client selected another identity, the key is not in the agent, or the path is wrong. | Use -i, an SSH config entry, or ssh-add and retest. |
| Only a local passphrase prompt appears. | The encrypted private key is being unlocked successfully or awaiting the correct passphrase. | Use the key passphrase; do not change remote password settings. |
A second prompt can also represent keyboard-interactive authentication, which may be a password, one-time code, or another challenge. The wording alone is not enough; the verbose log and server policy identify the method.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Windows OpenSSH has different key paths and ACL rules
For a Windows OpenSSH server, Microsoft documents %programdata%sshsshd_config as the default server configuration file. Changes to that file require restarting the sshd service after validation.
Recommended Free Tools
Standard users
The normal user key file is .sshauthorized_keys under that user’s profile. Confirm that the profile in question matches the username in the SSH command and that the file is not in another account’s profile.
Members of the local Administrators group
Administrator accounts may use %programdata%/ssh/administrators_authorized_keys instead of the per-user file. Microsoft requires restrictive ACL entries for SYSTEM and BUILTINAdministrators on this file. An ACL that grants broad access can cause the server to reject the file even when the public-key line is correct.
Windows troubleshooting sequence
- Run the client test with
ssh -vvv -i C:pathtoprivate_key user@hostand confirm the username and offered identity. - On the server, determine whether the account is an administrator and therefore subject to the administrator key path.
- Check the effective
AuthorizedKeysFileand any included configuration orMatchrule. - Inspect the file ACLs, especially the administrator key file, and remove unauthorized write or access entries according to Microsoft’s documented requirements.
- Validate the edited configuration, restart
sshd, and test from a second client session while keeping your current access available.
Use the failure layer to choose the fix
| Failure layer | Evidence in the log or environment | Fix to try first |
|---|---|---|
| Prompt interpretation | The prompt appears before any network authentication, while loading a private key. | Enter or manage the local key passphrase; investigate the private-key file if it is rejected. |
| Client identity selection | The intended identity is not listed or is not offered. | Specify -i, correct IdentityFile, or load the key into the agent. |
| Account or host mismatch | The debug output shows another username or hostname than expected. | Correct the SSH command, alias, DNS record, or deployment target. |
| Server key lookup | The key is offered but rejected; the file path or dynamic key command is uncertain. | Inspect effective AuthorizedKeysFile/AuthorizedKeysCommand and install the matching public key for that account. |
| Filesystem trust | The path is correct but permissions or ownership are unsafe. | Apply the target platform’s documented restrictive ownership and permissions. |
| Authentication policy | The key succeeds and a password or interactive challenge still follows. | Confirm whether a sequence such as publickey,password is intentional. |
| Platform-specific rules | Unix checks pass, but a Windows administrator account still fails. | Check the Windows administrator key path, ACLs, and service restart. |
A safe end-to-end troubleshooting procedure
- Classify the prompt. Decide whether it is the local private-key passphrase or the remote account password.
- Run a controlled client test. Use
ssh -vvv -i /path/to/private_key user@hostso the username, host, and identity are explicit. - Read the identity section. Confirm that the intended key is loaded and offered, not merely that SSH found some key file.
- Verify the pair. Ensure the public key installed on the server corresponds to the private key selected by the test.
- Verify the account and host. Check that the key is installed for the named account on the actual destination server.
- Resolve the server path. Inspect
AuthorizedKeysFile, included files,Matchblocks, and anyAuthorizedKeysCommand. - Fix trust controls. Correct ownership, permissions, or Windows ACLs on the home/profile path, key directory, and key file.
- Check policy. Determine whether
AuthenticationMethodsintentionally requires a password or interactive challenge after the key. - Validate safely. Test configuration syntax, keep the current session open, restart only when required, and verify a new login before disabling fallback authentication.
Security choices after key login works
Once a key-only login is proven, decide whether removing password fallback is appropriate for the account and environment. A key passphrase protects the private key if the client device is lost, while a server policy that combines publickey with password deliberately preserves two authentication steps. Security-key algorithms and controls such as requiring a hardware touch or user verification are separate hardening options; they do not repair an incorrect key path, wrong account, or unsafe permissions.
Do not remove a required second factor merely to silence a prompt. The correct outcome may be to keep the password or keyboard-interactive step and document it as intentional. If the goal is single-factor key login, change policy only after confirming that the key is accepted and that an emergency access path remains available.
Quick Recap
Quick checklist
- Is the prompt for a local key passphrase or the remote account password?
- Does
ssh -vvvshow the intended username, host, and private key being offered? - Does the installed public key match that private key?
- Is the key under the target account’s effective
AuthorizedKeysFileor supplied by its configured command? - Are the home/profile directory,
.ssh, andauthorized_keysownership and permissions trusted? - Is the key present in the expected SSH agent, if an agent is being used?
- Do included files or
Matchblocks alter the policy? - Does
AuthenticationMethodsintentionally requirepasswordorkeyboard-interactiveafterpublickey? - On Windows, is the account an administrator using
%programdata%/ssh/administrators_authorized_keys, with the required ACLs and a restarted service? - Have you tested a new session before disabling password authentication?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
