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 problemsiTechGuides 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
If SSH returns Permission denied (publickey)., first confirm you are connecting to the right host as the right account. Then check which private key your client offers, whether it is unlocked, whether its matching public key is installed for that account, and whether the server accepts the key file’s path and permissions. The same checks apply to VPS and VDS; the operating system image and SSH configuration—not the hosting label—determine the details.
Why does SSH say Permission denied (publickey)?
SSH public-key authentication uses a pair: your client proves it has the private key, while the server checks whether the matching public key is authorized for the account you named. The private key stays on your client; install or copy only its public-key counterpart, usually the file ending in .pub. Ubuntu’s setup guide describes generating and installing a key pair in its OpenSSH server guidance.
The message means public-key authentication did not get you in. It does not, by itself, establish whether the client offered the wrong key, the server could not find the authorized key, or a server-side rule rejected it. A password prompt after a key attempt is not proof that the key is invalid: determine whether the intended identity was offered and how the server handled it.
VPS and VDS are hosting labels, not SSH behavior guarantees. The distribution, OpenSSH version and configuration, account, network path, and provider setup all matter. Ubuntu-specific examples below apply to Ubuntu; another image may use different service names, paths, defaults, or recovery tools.
#1 Best Overall
Check the connection target and login account first
Confirm the hostname or IP address, SSH port, and username. A key authorized for one user does not automatically authorize a different user. The server looks up keys for the account being used, in that account’s configured authorized-key file.
- Check the destination and port in the SSH command or saved host configuration.
- Check the username explicitly; do not assume the provider’s default login name is the account for which the key was installed.
- If you can access the server through another route, verify that the public key is installed for this exact account.
On Ubuntu, the documented installation command is ssh-copy-id username@target_machine; substitute the real account and host. This installs a public key for that named remote user, rather than making it valid for every account.
Find out which private key the client offers
Use verbose client output to see identity selection and the authentication exchange. For example, run ssh -v user@host; use -vv or -vvv for more detail if needed. Look for lines indicating which identity file is considered and whether a key is offered. The Ubuntu community troubleshooting page demonstrates verbose debugging for this error: SSH/OpenSSH/Keys.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If the client is trying several keys, explicitly select the intended private key with ssh -i /path/to/private_key user@host. Do not paste or upload that private key to the server. If you connect to the same host repeatedly, Ubuntu’s guide explains configuring the identity per host in ~/.ssh/config; verify the resulting settings when diagnosing a mismatch.
Check that the key is available and unlocked
A passphrase-protected private key must be unlocked before it can sign the authentication request. If the key is managed by an SSH agent, confirm the agent is running and has the intended identity loaded. The Ubuntu guide covers passphrases and ssh-agent; its troubleshooting page also uses ssh-add to investigate agent-related problems.
When the client reports that it cannot sign with an identity, or that no suitable identity is available, address that locally before changing server files. Ensure you are using the expected key path and, where relevant, add the key to the active agent with ssh-add /path/to/private_key. Keep the passphrase and private-key contents private.
Verify the public key is installed for the account
The server must consult a file containing the public key that matches the private key offered by the client. OpenSSH’s sshd(8) documentation describes the default authorized-key locations and the one-key-per-line format. The setting AuthorizedKeysFile can change the path, so inspect the active configuration rather than assuming every system uses the default: Ubuntu Noble sshd(8) manual.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchIf you have authorized access through a console or another account, check the target user’s authorized-key file and confirm the corresponding public-key line is present. Avoid confusing a private key with a public key: the server needs the public key, not a copy of your private key.
Check ownership and permissions along the whole path
OpenSSH may reject a key when the authorization path can be modified by an unauthorized user. Check the account’s home directory, its .ssh directory, and the authorized-key file—not only the final file. The OpenSSH manual explains that the authorized-key file must be owned by the user and not writable by anyone else, and that unsafe writable paths can lead to rejection when StrictModes is in effect. Ubuntu’s guide likewise advises limiting write access to the authenticated user.
Rank #4
Inspect ownership and mode before changing them. Choose values that fit the account and operating system; do not loosen permissions or disable StrictModes as a shortcut. The Ubuntu community troubleshooting page includes permission diagnostics, but older advice there should not override the installed OpenSSH manual or effective configuration.
Use server logs and effective configuration to locate server-side rejection
If the client offers the intended key and the account’s key file appears correct, check whether the daemon permits public-key authentication and which authorized-key path and restrictions are active. Account allow/deny rules, Match blocks, key options, revoked-key lists, or provider-installed configuration can affect an otherwise valid key. The applicable settings are installation-specific; the OpenSSH manual documents authorized-key lookup and revoked keys.
Recommended Free Tools
Client output shows what the client attempted. Server authentication logs can explain what the daemon rejected or could not find. On Ubuntu, the documented live journal command is journalctl -fu ssh.service. Other distributions may use another service name or logging location, so identify the system’s service and log setup before restarting or changing the daemon. Where the configuration supports it, inspect the effective settings rather than relying only on a file you expect the daemon to read.
Best Value
Use key-generation guidance in context
For new keys, Ubuntu Server documentation recommends the Ed25519 algorithm, stating: “We recommend the ed25519 Elliptic Curve algorithm (-t ed25519) due to shorter key size and lower computational requirements.” It shows ssh-keygen -t ed25519 and lists RSA with a 4096-bit key as an alternative. This is Ubuntu’s documented recommendation, not a finding from a live VPS test. The Ubuntu Noble sshd(8) manual states that its daemon enforces a minimum RSA modulus size of 1024 bits; that is a version-scoped implementation limit, not a recommendation to create 1024-bit RSA keys.
If SSH access is completely lost
Use the hosting provider’s console or rescue environment only according to that provider’s instructions. Recovery interfaces and steps vary, and there is no universal VPS or VDS procedure. Once you regain administrative access, inspect the intended account’s authorized keys, permissions, daemon configuration, and logs before changing authentication safeguards.
Also distinguish account-password status from public-key authorization. Locking or disabling a password does not remove access granted by an existing public key. To revoke SSH access, review authorized keys and any applicable access-control rules.
Quick Recap
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.
