Vultr SSH Key Setup: Connecting From the Terminal Without a Password

Q: What username do I use to SSH into a Vultr server?

Vultr's own distribution images generally use root. Marketplace and one-click applications often use ubuntu, admin, or an application-specific user. If root gives permission denied, try ubuntu before concluding the key is at fault.

Q: What does Permission denied (publickey) mean?

The server rejected your key. Run ssh -v and look for an Offering public key line — if it appears and is then denied, the key is not in the server's authorized_keys or the permissions on ~/.ssh are wrong. If it does not appear, your client never presented the key.

Q: What permissions do SSH key files need?

On the client, 700 on ~/.ssh, 600 on the private key. On the server, 700 on ~/.ssh and 600 on authorized_keys, and the home directory must not be group- or world-writable. The client complains loudly about its own permissions; the server fails silently about the server's.

Generate a key with ssh-keygen -t ed25519, paste the .pub file into your Vultr account, and attach it during instance deployment — not after. Then ssh root@your-server-ip connects with no password. A key added after the instance exists is not on that instance, which is the single most common reason this does not work first time.

The mechanics are straightforward and the failure modes are all small. Most of the time this works in five minutes; when it does not, it is one of four things, and none of them are subtle once you know to look.

Generating the key
Adding it to Vultr, before you deploy
Connecting, and the username question
The permission rules SSH enforces
Hardening once keys work
How this fits the rest of the stack
FAQ

Generating the key

ssh-keygen -t ed25519 -C "you@example.com"

Accept the default location (~/.ssh/id_ed25519) unless you are managing several keys. Set a passphrase — with an agent holding it, you type it once per session rather than per connection, so the security is close to free.

Use ed25519 rather than RSA. It is shorter, faster to verify, and has been the sensible default for years. If you hit a system too old to accept it, ssh-keygen -t rsa -b 4096 is the fallback.

This produces two files, and the distinction matters more than anything else here:

id_ed25519 — the private key. Never leaves your machine. Never gets pasted anywhere.
id_ed25519.pub — the public key. This is what you upload.

Copy the public key:

cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... you@example.com

Take the whole line, including the ssh-ed25519 prefix and the trailing comment. A key pasted without the prefix is not a valid key, and the error you get later says nothing about it.

Adding it to Vultr, before you deploy

In the Vultr portal, go to Account → SSH Keys and add the public key with a name identifying the machine it came from. That stores it in your account; it does not put it on any server.

The step people miss: you must select the key during instance deployment. On the deploy page there is an SSH Keys section — tick your key there. Vultr writes it into /root/.ssh/authorized_keys when the instance is provisioned.

Add a key to your account after an instance is already running and that instance knows nothing about it. Vultr emails you a root password for instances deployed without a key, and that is what you will need in order to add the key yourself:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your-server-ip

That prompts for the emailed password once, appends your key to authorized_keys with the right permissions, and from then on you are on keys.

Without ssh-copy-id — it is missing on Windows and some minimal systems — the manual equivalent is:

cat ~/.ssh/id_ed25519.pub | ssh root@your-server-ip \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Connecting, and the username question

ssh root@203.0.113.42
ssh -i ~/.ssh/id_ed25519 root@203.0.113.42     # if the key is not the default

Vultr’s own images generally use root. Cloud images from distribution vendors often do not, and the marketplace apps vary:

Vultr Ubuntu, Debian, Rocky, AlmaLinux — root
Some marketplace and one-click applications — ubuntu, admin, or an app-specific user
A custom uploaded image — whatever that image was built with

If you get Permission denied (publickey) with root and are not sure, try ubuntu before assuming the key is wrong. The verbose output tells you what actually happened:

ssh -v root@203.0.113.42 2>&1 | grep -E "Offering|Authentications|denied"

Offering public key: ... followed by a denial means the server received your key and does not have it in authorized_keys — a key placement problem. No Offering line at all means your client never presented the key, which is a local problem.

Save yourself the flags with a host entry in ~/.ssh/config:

Host myvps
  HostName 203.0.113.42
  User root
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Then ssh myvps. IdentitiesOnly yes is worth including — without it, your agent offers every key it holds, and a server configured with a low MaxAuthTries disconnects you before it reaches the right one.

The permission rules SSH enforces

SSH refuses to use key material that other users could read, and it does this silently enough to be confusing. On the client:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

A private key readable by others produces a blunt refusal:

Permissions 0644 for '/home/you/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

The same rules apply on the server, and there they fail quietly — the server just declines the key without saying why in the client output:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

The home directory itself must also not be group- or world-writable, which catches people who ran a broad chmod 777 at some earlier point. The server’s log is definitive here:

journalctl -u ssh -n 30
# "Authentication refused: bad ownership or modes for directory /root"

Hardening once keys work

Do this only after confirming key login works, and keep a second session open while you do it — locking yourself out of a VPS means using the web console to recover.

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Validate before restarting, because a syntax error here means sshd will not come back:

sudo sshd -t && sudo systemctl restart ssh

Disabling password authentication is the single most valuable change. A public-facing SSH port sees continuous automated password guessing; with passwords off, that traffic becomes noise rather than risk.

Worth doing alongside it:

Create a non-root user with sudo and stop using root directly.
Enable Vultr’s firewall and allow SSH only from addresses you use, if they are stable.
Install fail2ban to drop repeat offenders and keep the logs readable.
Keep a backup key on a second machine, or keep the console password somewhere you can find it.

How this fits the rest of the stack

Everything above is setup work you do once per server and then repeat on the next one — key placement, permissions, hardening, firewall rules, keeping the console password somewhere findable. It is not difficult; it is just a recurring tax on running your own boxes, and it grows linearly with how many you have.

The alternative is not doing it at all. RunxBuild deploys services and static sites from a GitHub repository with no server to log into, no key to place and no SSH surface to harden — the deploy is a build and a live route, and the logs are in the dashboard rather than behind a session. If you want to compare that against what you are paying for a VPS you administer yourself, the RunxBuild hosting calculator breaks out the service, database, storage and bandwidth individually.

Useful related references:

FAQ

Why does my Vultr SSH key not work after adding it?

Because adding a key to your Vultr account does not add it to existing instances. The key must be selected during instance deployment. For a server that already exists, log in with the root password Vultr emailed you and run ssh-copy-id to install the key.

What username do I use to SSH into a Vultr server?

Vultr’s own distribution images generally use root. Marketplace and one-click applications often use ubuntu, admin, or an application-specific user. If root gives permission denied, try ubuntu before concluding the key is at fault.

What does Permission denied (publickey) mean?

The server rejected your key. Run ssh -v and look for an Offering public key line — if it appears and is then denied, the key is not in the server’s authorized_keys or the permissions on ~/.ssh are wrong. If it does not appear, your client never presented the key.

What permissions do SSH key files need?

On the client, 700 on ~/.ssh, 600 on the private key. On the server, 700 on ~/.ssh and 600 on authorized_keys, and the home directory must not be group- or world-writable. The client complains loudly about its own permissions; the server fails silently about the server’s.

Should I disable password authentication on my VPS?

Yes, once you have confirmed key login works and while a second session is still open. A public SSH port receives constant automated password guessing, and turning passwords off makes that traffic harmless. Validate the config with sshd -t before restarting.