The error below means the SSH server rejected every key offered, and on a rented GPU the reason is almost always something about this specific launch rather than a broken key.
Permission denied (publickey).
The username is wrong for this provider
This is the fix that works most often, because the login user is not the same everywhere: ubuntu on QuantaCloud and Hyperstack, Ubuntu with a capital U on Massed Compute, and root on Verda. Copy the exact command from the deployment in the dashboard instead of reusing one from a different provider or an old guide:
ssh -i ~/.ssh/id_ed25519 ubuntu@YOUR_VM_IP
Swap in the user shown on your deployment. A capital letter typed in lowercase is enough to produce this exact error.
The key file is not the one you think
SSH tries your default keys first, which is not always the key added to this deployment. Point at the exact private key file with -i:
ssh -i ~/.ssh/id_ed25519 ubuntu@YOUR_VM_IP
If a key pair was generated in the DeployGPU dashboard, the private half was shown once, at creation. Saved under a different name than the default id_ed25519 or id_rsa, -i is not optional.
The key's file permissions block SSH from using it
OpenSSH refuses a private key that other users on your own machine can read. Fix the permissions directly:
chmod 600 ~/.ssh/id_ed25519
The dashboard did not attach this key to this launch
The dashboard attaches one SSH key per launch, the one selected on the deploy page at the time. Adding a new key afterward does not reach machines already launched. Add the key on the SSH keys page first, then launch a new deployment with that key selected. The API behaves differently: it attaches every key on the account unless specific ones are listed in ssh_key_ids.
QuantaCloud rejected an ECDSA-only key
QuantaCloud accepts RSA and Ed25519 keys, not ECDSA. If the only key on the account is ECDSA, a QuantaCloud launch fails outright with the code SSH_KEY_MISSING rather than handing over a machine to test SSH against at all. Add an RSA or Ed25519 key and relaunch.
The signup key was never downloaded
DeployGPU generates a default Ed25519 key called Default Key at signup, and shows its private half exactly once, for about 10 minutes. If that window closed before it was saved, the key still exists on the platform but is unusable, because nobody, including DeployGPU, can show that private half again. Add a new key and use it on the next launch.
Too many keys in your SSH agent
An SSH agent offering five or six keys before the right one can hit the server's limit on failed attempts, which looks identical to a wrong key. Tell the client to use only the key specified instead of letting the agent try everything it holds:
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 ubuntu@YOUR_VM_IP
Ask ssh itself what happened
When none of the above explains it, -v shows exactly which keys were offered and why the server turned each one down:
ssh -v ubuntu@YOUR_VM_IP
The lines starting with debug1: Offering public key and debug1: Authentications that can continue are the ones to read. They name the exact key that was tried and what the server still accepts.
When to contact support
Contact support if ssh -v shows the right key was offered and still refused, on a deployment you launched with that key selected. That combination points at something on DeployGPU's own side rather than yours. The contact page is the way in, and the SSH guide covers setting up ~/.ssh/config so this is less to get wrong next time.
Frequently asked questions
Why does Massed Compute need a capital U in the username?
The provider's own Ubuntu image creates the account as Ubuntu, not ubuntu, and Linux usernames are case-sensitive. Copy the exact command from the dashboard rather than typing it from memory.
I added a new SSH key. Why does my running instance still reject it?
Keys are attached at launch, not afterward. A key added after a deployment is already running has to wait for the next launch to take effect.
Can I use an ECDSA key on DeployGPU?
On most providers, yes. QuantaCloud is the exception: it accepts only RSA and Ed25519 keys, and an ECDSA-only launch there fails before a machine is even handed over.
I lost the private key from signup. What now?
Add a new key from the SSH Keys page and use it on the next launch. The original private half is shown only once and cannot be recovered.
Does anything have root access to my instance without my key?
DeployGPU keeps an encrypted platform-managed key for each account. It is installed on Verda VMs and used as a fallback on some other providers when a deployment has no key of yours. You control the keys you add, and this is worth knowing rather than assuming otherwise.
What should I copy from the dashboard instead of typing by hand?
The full ssh command shown on the deployment, including the user, the host and the port. Retyping it from memory is where the username and port most often go wrong.