Check the rejected SSH key
Permission denied (publickey) reached authentication. Check the target, user and offered identity before server-side investigation.
This error means SSH reached authentication without an accepted login; it does not prove the server checked a particular authorized_keys entry. Wrong user, unoffered key, policy or rejected signature are possible. Timeout, refusal and host-key warnings need separate diagnosis.
This guide is for an account you are authorised to use on a Novasean-hosted VPS. Keep any existing working session open while diagnosing a failed new login. Do not disable public-key authentication, enable root or password login, or reinstall the VPS to test a guess.
Confirm the destination, account and offered identity
Check the VPS address or hostname, SSH port and permitted account name against the service record. A panel login name is not automatically a Linux login name. Run ssh -G -p 2222 user@203.0.113.10 after replacing the reserved example address, user and illustrative port with the approved values. Omit -p 2222 only if the approved port is 22 or a verified SSH host alias already selects the correct port. Use the same approved destination, account and port for the diagnostic login below; a host alias and a literal IP can select different client configuration rules. Inspect the effective hostname, user, port, identityfile and any proxy settings; local Host and Match rules can change what is sent. This command prints configuration and does not log in. Do not publish its complete output without checking for private host details.
Then retry once with client diagnostics, for example ssh -vvv -p 2222 -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@203.0.113.10, replacing the example account, address, illustrative port and key path with the approved values (or omitting -p 2222 under the same verified port condition). The -i option selects a specific identity; IdentitiesOnly=yes limits identities offered from an agent or provider to configured ones. If the approved key is held only by an agent or hardware token, follow that identity's supported client setup rather than assuming this sample private-key file exists. Redact hostnames, usernames and any sensitive configuration before sharing a diagnostic log. Never send the private key or its passphrase.
Use the client trace to choose the next check
Look for the intended destination and account, followed by whether the client says it is Offering public key for the expected identity. If it offers no suitable identity, check the local key path, agent or hardware-token availability and the effective configuration. A newly generated key will not grant access until its public half is installed through an authorised recovery path. If it offers a key but the server rejects it, do not keep trying random identities; compare that key's public fingerprint with the one authorised for the target account, and have the server-side policy checked.
A message that the server accepts a key is not always the end of authentication: the client still has to prove possession of the private key, and the server may require another method. Keep the surrounding diagnostic lines and any server log entry so the failure can be located precisely. If the error is a host-key change instead, stop and use the host-identity guide before accepting a new host key.
Illustrative branch: the SSH trace shows no offer of the expected key, so check the local path or agent first. An offered but rejected key needs the authorised account and server policy checked.
Inspect the target account only through an approved recovery route
If you have an already working administrator session or an approved VPS console, inspect the intended account's home directory and configured authorised-key location. OpenSSH normally uses an AuthorizedKeysFile relative to that account's home, but an administrator may configure another path or a different key authority. Confirm that the intended public key belongs to that account and has not been revoked. Check ownership and permissions on the account home, .ssh directory and key file without changing them first. With StrictModes enabled, OpenSSH may refuse a key if those paths are writable by other users. Symlinks, access controls and system policy can also matter; blanket recursive ownership or permission changes are unsafe.
An authorised server administrator should inspect the SSH service log for the exact attempt time and relevant effective sshd_config policy, including PubkeyAuthentication, AuthorizedKeysFile, account allow/deny rules and applicable Match blocks. Use the actual server distribution's logging instructions. Do not edit sshd_config or replace authorized_keys without a verified recovery path and rollback plan. A browser console, if available, is a recovery channel; it is not proof that the account has root privileges.
An offered key may still be rejected by account policy or permissions. Avoid blanket chmod or ownership changes without a matching server log.
Restore access and prove the fix
Correct only the cause confirmed by client and server evidence. That might be selecting the approved identity or account on your device, restoring an authorised public key for the correct account, or having the responsible administrator repair a specific policy or ownership fault. Preserve the existing working session until a fresh SSH login succeeds from a second terminal. Confirm the new session reaches the intended VPS and account before closing the recovery route.
If you have no approved console or working administrator route, ask Novasean support to establish the recovery options for your service. Include the service identifier, intended account, attempt time and time zone, exact error, relevant redacted ssh -vvv lines and the public-key fingerprint if known. Do not send passwords, private keys, passphrases or a full unredacted client configuration. Novasean can check the service boundary and available recovery route; a particular self-service console or administrator entitlement must not be assumed.
Common questions
Why did SSH not offer a password prompt? The server decides which authentication methods are available for this connection and account; the final error lists methods still available to the client, not necessarily every reason the public key failed. Check the approved service policy before changing it.
Would opening port 22 or disabling a firewall solve this? A completed SSH authentication exchange has already passed the network connection stage. Investigate a timeout or refusal as a separate transport issue; do not relax firewall rules solely because a key was rejected.
Should I copy the private key to the VPS? No. The server needs the approved public key or another configured trust mechanism; the private key stays under your control.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.