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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The error means your VPS was reached, but its SSH server rejected the public-key identity offered for the account. In most cases, the cause is a wrong username or private key, a missing or malformed key in authorized_keys, unsafe ownership or permissions, an sshd policy mismatch, or a client agent using a different key. Start by running ssh -vvv, then work through the account, key file, permissions, server policy, and console-recovery checks below.
What “Permission denied (publickey)” actually means
SSH has reached the server and started authentication. This is different from a timeout, “No route to host,” or “Connection refused,” which indicate network reachability or a listening-service problem. With Permission denied (publickey), the server did not accept any public-key identity presented for the requested account.
Public-key login uses a pair. The private key remains on the computer from which you connect; the matching public key is stored on the VPS in the target account’s configured authorized-keys file. The client proves it possesses the private key, and sshd verifies the signature against the stored public key. A valid key installed for one account does not authenticate a different account, and a different private key cannot authenticate even when another key is correctly installed.
The default authorized-key locations documented by OpenSSH are ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2, unless the server’s sshd_config changes AuthorizedKeysFile. Images supplied by VPS providers can also set a different login name, home directory, or policy.
Start with a verbose client diagnosis
Run the connection with maximum SSH client diagnostics:
ssh -vvv user@serverReplace user and server with the exact account and hostname or address supplied for your VPS. Linuxize’s SSH troubleshooting guidance recommends -v, -vv, or -vvv; the additional detail is especially useful when an agent offers several identities.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Read the output in sequence rather than jumping to the final error:
| Verbose output area | What it tells you | Likely next action |
|---|---|---|
| Connection and host-key exchange | The client reached an SSH service and negotiated a protocol. | Focus on authentication, not firewall or routing changes. |
| Identity files and “Offering public key” | Which keys the client found and attempted. | Check that the intended private key appears; use -i to select it explicitly. |
| “Server accepts key” followed by signing | The public key is recognized and the client is proving possession of the private half. | Investigate agent signing, account restrictions, or a later policy failure if login still stops. |
| “Authentications that can continue: publickey” | The server still allows public-key authentication but rejected the offered identity. | Verify username, key pair, authorized-key content, and file permissions. |
| Agent-signing or “no mutual signature” messages | The agent supplied an unusable key or the client and server cannot use that key algorithm. | Load the intended key directly with ssh-add and retry; then inspect server policy. |
Do not paste private-key material into a support ticket or shell transcript. Verbose output normally reveals filenames and public-key fingerprints, not the private key itself, but review it before sharing.
Fix 1: Confirm the exact account and private key
Use the provider’s login name
Cloud images often disable direct root login and create an image-specific user. Other images use a distribution-specific administrator name. Do not assume that the username on one VPS image applies to another. A wrong username makes sshd search a different home directory and therefore a different authorized-keys file.
Connect with the exact account named by the provider:
Free tools Windows power users keep installed
One-click scans. No signup required.
ssh user@serverIf your local SSH configuration, shell alias, or copied command may be substituting another account, specify it directly with the user@host form. Avoid adding sudo to the client command as a troubleshooting shortcut. GitHub’s SSH guidance notes that running the client through sudo can switch to another user’s home directory, keys, and agent.
Select the intended private key explicitly
When several keys exist, force the expected one:
ssh -i ~/.ssh/id_ed25519 user@serverThe path must point to the private half of the pair whose public half is installed on the VPS. If the verbose log never shows an offer for that identity, check the path and local read access. If it offers a different key first and the server rejects it, the explicit -i option removes that ambiguity.
Keep the account and key context together: a key copied for an administrator account will not work when you connect as an application user unless that user’s authorized-key file also contains the matching public key.
Fix 2: Verify the public key on the VPS
You need an existing administrative SSH session or an out-of-band provider console for this step. Switch to the account that should receive the key, then inspect its configured file. The public key must be present as one complete line; wrapped lines, truncated text, or an accidental second line make it unusable.
- Identify the target account and its home directory. Do not edit another user’s file simply because that file is easier to find.
- Open the account’s
.ssh/authorized_keysfile, or the path specified byAuthorizedKeysFilein the effectivesshdconfiguration. - Confirm that the line corresponds to the public half of the private key you are selecting locally.
- Remove only demonstrably damaged duplicate or wrapped text; preserve other valid administrator keys unless you have a documented reason to revoke them.
OpenSSH documents .ssh/authorized_keys and .ssh/authorized_keys2 as defaults, but an included configuration file can override them. If the key was installed under a different home directory, correcting the file content alone will not help until the username and path match.
Fix 3: Repair ownership and permissions
OpenSSH may reject a key when the home directory, .ssh directory, or authorized_keys file is writable by inappropriate users or owned by the wrong account. Google Cloud identifies incorrect ownership or permissions on all three locations as common SSH failure causes. Check every directory component leading to the file, not just the file itself.
While logged in through a provider console or another administrative account, run the following as the target user (or substitute the target user’s home path deliberately):
chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysThese commands remove group and other write permission from the home directory, restrict .ssh to the account, and make the authorized-key file readable and writable only by its owner. The documented Ubuntu example uses these modes. Distribution images can impose additional requirements, so inspect the current modes before applying broader changes.
PC 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 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchEnsure ownership is correct. From an administrative shell, replace user and /home/user with the actual account and home directory:
chown user:user /home/user
chown -R user:user /home/user/.sshDo not run a recursive ownership change against a shared or unusual home directory without checking its contents first. The key file should be owned by the account that will log in, and each parent directory must be traversable by that account. If the image uses a nonstandard home path, apply the same checks to that path rather than assuming /home/user.
Fix 4: Inspect the effective sshd policy
A correctly installed key can still fail when the server policy disables public-key authentication, points AuthorizedKeysFile elsewhere, restricts the account, or overrides settings in an included configuration file.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems- Confirm that public-key authentication is enabled. OpenSSH lists
publickeyamong the available authentication methods alongside methods such aspassword. - Find the effective
AuthorizedKeysFilevalue, including settings loaded from configuration files under anIncludedirective. - Check account restrictions such as an invalid shell, a denied user/group rule, or a host-specific
Matchblock. - Review the server log while making one test connection; it often names the rejected path or permission problem.
Use your distribution’s configuration-test command before restarting the daemon. On systems that provide it, a typical check is:
sshd -tSome distributions require an explicit configuration path or a service-manager wrapper. Use the command documented for that image. A successful syntax check does not prove that the desired account, key path, and permissions are correct; it only prevents an avoidable restart with invalid syntax.
After validating the configuration, restart or reload SSH through the distribution’s service manager. Keep an existing session open while testing a new one so a policy mistake does not remove your only access.
Fix 5: Correct a local SSH-agent problem
An SSH agent can offer a key different from the one you intended, or fail when asked to sign. The verbose client output identifies agent use and signing errors. Load the intended private key explicitly:
Recommended Free Tools
ssh-add ~/.ssh/id_ed25519Then retry with:
ssh -vvv -i ~/.ssh/id_ed25519 user@serverVerify in the diagnostic output that the expected identity is offered. If the agent contains many stale keys, remove only the incorrect identity or start a clean agent for the test rather than deleting key files. A successful key offer followed by server rejection still requires the server-side checks above; loading a key into the agent cannot repair a missing authorized-key line or bad ownership.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Recover access when every SSH attempt is rejected
When no SSH session remains, use the VPS provider’s web console, serial console, rescue environment, or maintenance mode. Google Cloud documents serial-console and maintenance-mode recovery for SSH failures; other providers expose different names and workflows.
- Open the provider’s out-of-band console for the affected VPS and authenticate through the provider-supported administrative route.
- Identify the intended login account and home directory before editing files.
- Restore the complete public key to that account’s configured
AuthorizedKeysFile. - Repair ownership and permissions on the home directory,
.ssh, andauthorized_keys. - Inspect the effective
sshdpolicy and included files. Make only the smallest necessary change. - Run the distribution’s SSH configuration test, such as
sshd -twhere supported. - Reload or restart the SSH service through the image’s documented service manager.
- Keep the console session open and test a new SSH connection from your workstation with
ssh -vvv.
If the console boots a rescue or maintenance system, the VPS filesystem may be mounted under a temporary path rather than its normal root. Apply changes to the mounted VPS filesystem, not to the rescue system’s own ~/.ssh. Follow the provider’s instructions for mounting and unmounting volumes, and make a backup of the existing key file before editing it.
Choose the least risky fix
| Fix | Where the fault is observed | Access required | Security and reversibility | What changes |
|---|---|---|---|---|
| Select the correct username and key | Client command or identity offer | Only the local workstation | Highly reversible; no server policy change | Selects existing account and key material |
| Restore the public key | Target account’s authorized-key file | Existing SSH session or provider console | Reversible by editing one line; preserve other valid keys | Changes server-side key material |
| Repair ownership and modes | Home, .ssh, or authorized_keys |
Administrative shell or console | Usually reversible; avoid broad recursive changes | Changes filesystem metadata |
Correct sshd policy |
Daemon configuration or account restrictions | Administrative shell or console | Higher impact; validate before reload and keep a session open | Changes authentication behavior or key-file location |
| Console or rescue recovery | Provider control plane or complete lockout | Provider web, serial, or maintenance access | Most operationally involved; allows recovery without SSH | Restores access outside the network SSH path |
Common dead ends and safer alternatives
Changing firewall rules first
A server that returns Permission denied (publickey) has already answered the SSH connection. Firewall changes will not make a rejected key valid and can create a second outage. Investigate authentication unless the verbose log shows a separate connectivity failure.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Trying an arbitrary username
Each username maps to its own home directory and authorized-key file. Repeatedly changing usernames can hide the real problem. Confirm the image’s documented account and inspect that account’s file.
Copying only part of a key
A public key is a single logical line containing its key type, encoded data, and optional comment. A wrapped or truncated line is not equivalent to the original public key. Copy it again from a trusted source and verify that the private key selected locally belongs to that public half.
Enabling password or root login permanently
Do not weaken authentication as a permanent workaround. If temporary console recovery requires a password or root setting, limit the change to the recovery window, validate the daemon, restore the hardened policy, and test key login before closing the console session.
Quick Recap
Prevent the next lockout
- Keep a second, tested administrative key on the VPS and store its private half securely.
- Verify that the provider’s web or serial console works before making SSH-only changes.
- Record the image-specific username, home directory, and key path alongside your deployment notes.
- After editing
sshdconfiguration, run its syntax test and open a separate test connection before ending the current session. - Use explicit host, username, and identity settings for critical servers so an agent’s unrelated keys cannot create ambiguity.
- Preserve the exact key type and account context shown by
ssh -vvvwhen troubleshooting.
A compact recovery checklist
- Run
ssh -vvv user@serverand note which identity is offered. - Retry with the provider’s exact username and
-ipointing to the intended private key. - Confirm the matching public key is one complete line in the target account’s configured authorized-key file.
- Check ownership and apply the documented restrictive modes to the home directory,
.ssh, andauthorized_keys. - Inspect effective
sshdsettings, includes, and account restrictions. - If an agent signs with the wrong key or fails, run
ssh-addfor the intended identity and retry. - If locked out, use the provider console or rescue mode, validate the daemon configuration, repair access, and test a new SSH session.
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.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →
