Ordering and first access

Root access is delivered exactly once, at first boot, as an SSH public key written to /root/.ssh/authorized_keys. There is no password, no emailed credential and no out-of-band channel. Everything on this page follows from that.

Store an SSH key first

Your keys live in the portal under Account settings → SSH Keys. Add the public key there before you order, because the order form only lets you pick from keys you have already stored.

Any public key OpenSSH accepts is accepted here, in authorized_keys form:

cat ~/.ssh/id_ed25519.pub

You can store up to 50 keys per account. A key must be active to be selectable at checkout: an inactive one is rejected before the payment, with ssh_key_invalid.

Ordering without a key is allowed, and it is the trap

The SSH key field at checkout is optional. Order without one and the server provisions and boots normally, with no authorized key and no root password, so nothing can log in to it.

It is recoverable, but only through the guest agent (see If you ordered without a key below), and only while the server is running. Pick a key at checkout unless you have a specific reason not to.

Placing the order

In the portal, Shop → VServer. You pick a hostname, an image, an SSH key and a plan, and the server goes into the cart like any other product.

The hostname is optional. Leave it blank and one is generated for you. It is also only a label, in the sense that it names the server in the portal, in alerts and in the ready email; it is applied inside the operating system at first boot, but renaming it later does not change the hostname inside a running server.

Two things are checked before your card is charged, so an order that cannot be fulfilled is refused rather than taken:

insufficient IPv4 addresses available
insufficient node capacity (memory or disk) for the requested size

Both come back as an error on checkout, not as a failed server later. A plan that is out of stock is also marked Sold out in the shop. If you instead get vserver capacity temporarily unavailable, please retry, stock could not be determined at that moment and the order was refused on purpose; try again.

While it provisions

The server appears in VServer in the portal with the status Provisioning and no IP address yet. It picks up an address, gets built, started, and flips to Active.

You get an email when it is up, with the IPv4 address, the IPv6 block and the specs. If you ordered with a key, that email also carries the login command.

If it ends in Failed, provisioning is retried automatically up to three more times. After that the server stays failed, billing for it is stopped, and the case is raised with us for a refund or a manual rebuild. The portal does not show you the reason, so if a server sits in Failed, contact support rather than reordering.

The first login

ssh root@<your-ip>

That is the whole of it: user root, the key you picked, the IPv4 address from the portal or the email. No root password is set, so there is nothing to type.

The IPv6 address works too, and is the first address in the block the portal shows you, not the block itself. See Networking.

If you ordered without a key

The portal shows a banner on the server: No access set up yet. Two ways out, both under Settings, and both need the server running and the guest agent answering:

• Install SSH key writes one of your stored keys into /root/.ssh/authorized_keys on the running server. By default it is appended; tick Replace all existing keys to overwrite the file with just that key.
• Reset root password sets a fresh random root password and shows it once.

Either one clears the banner.

The root password is for the console

The password from Reset root password is shown exactly once, in the dialog. It is not stored anywhere you can read it back, and we cannot show it to you again. Copy it before you close the dialog; if you lose it, run the reset again.

Use it at the Console tab, which is a keyboard and screen attached to the machine and does not care whether the network inside the server works. It is not an SSH login: the images ship with SSH password authentication switched off, and turning that on in sshd_config is something you would be doing to yourself, not something we recommend.

The guest agent

Installing a key into a running server and resetting the root password both go through a small agent inside the guest, which the image installs on first boot. Its state is on the Overview tab as Guest agent.

When it is not answering, those two actions fail with this, verbatim:

This action needs the QEMU guest agent running inside your server, but it
isn't responding.

Reinstall it from inside the server and the actions work again:

apt install qemu-guest-agent && systemctl enable --now qemu-guest-agent

Keep it installed. Besides the two recovery paths it is what makes a graceful shutdown graceful and what feeds the disk-full alert.

Flatcar Container Linux has no guest agent

Flatcar does not process the configuration that installs it, so Install SSH key and Reset root password will not work on a Flatcar server. Order it with an SSH key, and keep a second key on it.

A key you delete is still on the server

Deleting a key under Account settings → SSH Keys removes it from your key store, which stops it being offered at checkout and for Install SSH key. It does not touch any server it has already been installed on.

There is no remote revocation

Once a key is in authorized_keys on a running server, the only place to remove it is inside that server. The same is true of a root password you reset: nothing in the portal takes it back.

So if a private key or a root password leaks, edit /root/.ssh/authorized_keys and change the password on every server it reached. If you have lost access and cannot do that, the remaining option is a reinstall, which erases the disk.

Because of that, treat both as long-lived credentials. Keep private keys off shared machines, and prefer Replace all existing keys over appending when you are rotating rather than adding.

What's next

• Managing your server for power, console and snapshots
• Networking for the addresses and what reaches them