Access

SSH, your own keys, and what a reinstall does to them

Where your public key goes, how to add another one later, and what survives a machine being rebuilt.

Your machine is a real VM and SSH is a real door onto it. This page is about where your public keys go, how to add one later, and what a rebuild does to all of it — including one limitation that people hit before they read anything.

**Port 22 is closed to the internet today.** The rule that opens it is written and decided and has not been applied, so an ssh from your laptop currently times out rather than being refused. Until that changes, the terminal in your dashboard is the way onto the machine, and it is a full shell on the same account.

Where a key comes from

Keys live on your account, not on a machine. Add them under your profile, give each one a label, and pick which ones a machine gets when you buy it — the checkout has a key picker rather than a paste box for exactly that reason.

When the machine is handed to you, the keys you picked are written into ~/.ssh/authorized_keys on your workspace account. That write **replaces** the file rather than appending to it, and picking no keys at all removes it.

Which keys are on the machine

**Yours**, on your workspace account — the account a terminal and an ssh land on.
**Ours**, two of them, on root: one the fleet uses and one an operator uses. They are what re-issues your dashboard link when a session lapses, what applies fixes, and what lets support look at a fault.

The machine's dashboard lists what it actually trusts, whose each key is, and which of them can be removed — behind the gear, under **Access → SSH keys**. Yours can be removed there. Ours cannot: removing those is vmbox detach, which is described on trust and security, is permanent, and has no re-attach.

Adding a key after the machine exists

Use the machine's own dashboard. There is a key field in the **SSH keys** dialog and another on the last card, and either appends one key to your workspace account. Editing ~/.ssh/authorized_keys yourself in a terminal works too — it is your file.

**Adding a key to your account does not reach a machine you already hold, and removing one does not revoke it.** The account key ring decides what your *next* machine is built with. Nothing on this site pushes a key onto a running machine, and nothing pulls one back off — so treat the profile page as a list for future orders, and the machine's dashboard as the truth about what it trusts right now.

For the same reason, the key list on your machine's page here shows what the order asked for. It is not a reading of the machine.

What a reinstall does

A reinstall lays the provider's image down again. It destroys the disk — that is the point of it, and it is not reversible. What comes back afterwards is a fresh machine carrying your lease.

**The keys that were on the order are re-installed.** They come from a snapshot taken when you paid.
**A key you added afterwards is gone** — whether you added it to your account here or on the machine's dashboard. Add it again.
**A key you removed from your account after buying comes back**, because the order's snapshot is what is read.
**The machine gets a new name**, and the old one is retired permanently. Old bookmarks and any Host alias in your ~/.ssh/config stop working.
**A new one-time dashboard link** appears on the machine's page here. It is never emailed.
**The host key changes.** That is deliberate — a changed host key is the evidence we accept that a disk was really wiped, rather than an API call that returned success.

Because the host key changes, your own SSH client will refuse to connect and print a warning about the remote host identification having changed. That is correct behaviour on its part. Drop the old entry:

ssh-keygen -R <the machine's name>

The same thing happens when a machine you never touched is recycled and handed to somebody else, which is why we accept nothing weaker as proof: no disk crosses from one customer to another.

What the machine will not do

**No password login.** Password and keyboard-interactive authentication are off, verified against the server's own effective configuration rather than assumed. There is nothing to guess.
**No vmbox keys command.** Keys are managed from the dashboard or by editing the file.
**No ban list.** There is no fail2ban, deliberately: it answers password guessing, which cannot happen here, and it would ban addresses the fleet itself needs. What bounds a stranger instead is a 30-second login grace and a cap on unauthenticated connections.
**No sudo on the workspace account.** Reading the machine's own logs, or running vmbox detach, needs root — see logs, and what to send when something is wrong.

Wrong, out of date, or missing the case you have? Tell us. A page that describes the machine incorrectly is a fault, not a typo.

Where a key comes from

Which keys are on the machine

**Yours**, on your workspace account — the account a terminal and an ssh land on.

**Ours**, two of them, on root: one the fleet uses and one an operator uses. They are what re-issues your dashboard link when a session lapses, what applies fixes, and what lets support look at a fault.

Adding a key after the machine exists

For the same reason, the key list on your machine's page here shows what the order asked for. It is not a reading of the machine.

What a reinstall does

A reinstall lays the provider's image down again. It destroys the disk — that is the point of it, and it is not reversible. What comes back afterwards is a fresh machine carrying your lease.

**The keys that were on the order are re-installed.** They come from a snapshot taken when you paid.

**A key you added afterwards is gone** — whether you added it to your account here or on the machine's dashboard. Add it again.

**A key you removed from your account after buying comes back**, because the order's snapshot is what is read.

**The machine gets a new name**, and the old one is retired permanently. Old bookmarks and any Host alias in your ~/.ssh/config stop working.

**A new one-time dashboard link** appears on the machine's page here. It is never emailed.

**The host key changes.** That is deliberate — a changed host key is the evidence we accept that a disk was really wiped, rather than an API call that returned success.

ssh-keygen -R <the machine's name>

The same thing happens when a machine you never touched is recycled and handed to somebody else, which is why we accept nothing weaker as proof: no disk crosses from one customer to another.

What the machine will not do

**No password login.** Password and keyboard-interactive authentication are off, verified against the server's own effective configuration rather than assumed. There is nothing to guess.

**No vmbox keys command.** Keys are managed from the dashboard or by editing the file.

**No ban list.** There is no fail2ban, deliberately: it answers password guessing, which cannot happen here, and it would ban addresses the fleet itself needs. What bounds a stranger instead is a 30-second login grace and a cap on unauthenticated connections.

**No sudo on the workspace account.** Reading the machine's own logs, or running vmbox detach, needs root — see logs, and what to send when something is wrong.